2. Then use git's interactive rebase to rewrite this branch such that just the back-end commits are picked first, followed by the front end.
Probably how I'd do it, but I know it's not a popular workflow. The only project that I've seen publicly talk about expecting a changeset to rewritten from "history of fiddling around" into "series of incremental improvements to a codebase" is the linux kernel.
It's more work for every developer, and digs into more advance git operations, but it really helps keep the tree clean. Most projects don't have a velocity that requires such well-groomed changes, but this is an example of how failing that can make the history ugly and changes more difficult to work with.
My ex-employer (Meraki) was VERY insistent on people cleaning up their histories. It was very good not just for keeping a clean tree, but also for code quality - once you have code changes in neatly-separated commits with discrete chunks of functionality, any leftover test code or unrelated changes pop out immediately to both the original coder and the reviewer.
By the way, this also helps with the issue this developer faced because part of the problem seems to have been that the backend and frontend changes were mixed in the same commits (hence the ugly hack for committing). Doing this kind of history-cleaning as you go makes it much easier to manipulate the order of committing changes to master.
Probably how I'd do it, but I know it's not a popular workflow. The only project that I've seen publicly talk about expecting a changeset to rewritten from "history of fiddling around" into "series of incremental improvements to a codebase" is the linux kernel.
It's more work for every developer, and digs into more advance git operations, but it really helps keep the tree clean. Most projects don't have a velocity that requires such well-groomed changes, but this is an example of how failing that can make the history ugly and changes more difficult to work with.
For those interested why/how you'd rewrite a patch series: https://www.kernel.org/doc/html/latest/development-process/5... The 406 changes probably compress to less than 20.