I find that pairing is good for this. One of us usually chimes in about whether we've reached a good commit point. Sometimes we'll keep a running list of thing

I find that pairing is good for this. One of us usually chimes in about whether we've reached a good commit point. Sometimes we'll keep a running list of things we want to loop back to. For example, a rename to cuts across multiple files, some unrelated. I like those to be in separate commits for a cleaner history. While it is, as others have pointed out, sometimes easier to commit "messily" and clean up the history. This is very helpful in some cases, but I see it as tactical and not strategic. In particular it is easy to go far enough down a road that it becomes difficult to disentangle what ought to be separate commits, especially because you need to go back and run the tests on each independently before committing to master. So if I see a decent commit point (the tests pass!) I will prefer to take it then and there, before turning to refactoring or to the next step in the work. On those occasions where the ultimate solution was so unclear that we wandered around on a WIP branch for longer than a day or two, I sometimes forced into what I call Athena Commits (they spring fully-formed from the brow of Zeus). I tend to hold to the short headline, but typically I find we write longer narrative blocks and then longer dotpoint lists of subsumed changes. I dislike this position but, if I have to do it, then my successors to deserve to know why it happened and what, in an ideal world, the shorter steps in smaller commits might have looked like. One last tip: always always use `git add -p`. I've caught so many commented lines and half-baked thoughts and things intended for later commits this way.