Git's workflow is bad, but this doesn't fix it at all because the real problem in the first paragraph comes when that first paragraph occurs after you've alread

Git's workflow is bad, but this doesn't fix it at all because the real problem in the first paragraph comes when that first paragraph occurs after you've already made some commits, and that can only be solved by either uncommitting a bunch of stuff or committing the next code in the wrong order and then rebasing to rearrange and squash commits. > to facilitate the feature you're working on you decide to make a small architectural change elsewhere in the codebase Imagine this happens _after_ you've already made a bunch of commits. So you write some code. You make some commits. And then you run into a wall where you suddenly realize that you really should change something else and do the code in an early commit differently. Writing your commit messages in advance doesn't solve anything related to git. If you actually already knew all of the commits you'd need to make, you wouldn't ever suddenly decide half-way through to make an architectural change that you hadn't planned to make from the beginning. But you _don't_ already know all of the commits you're going to need to make. That's the problem, and this proposal doesn't address it. So now you make a new commit for the architecture change, and then you make a dummy commit for the code that uses the new architecture change, and then you git rebase interactive to move the dummy commit after the earlier commit and mark it as a fixup, and you move the architecture change commit before the whole thing, and then you pray that nothing is broken in the process.