I've found that separating work from recording that work is the easiest approach. So what I end up doing is waiting the code and tests and making sure things work as expected. Only then will I start recording that work into a sensible series of commits. To do this, I'll generate the diff of my work relative to the base branch and then stage parts of that work using the git apply command and make a commit out of it. I…
That sounds like too long to wait to commit, by my judgement. There's too much risk of loss of work, or at least annoyance getting it back via editor undo. What about making smaller commits and going back and editing it later? You could either 'git reset --soft' to "undo" some commit(s) and then craft them how you like, or anything else. Seems like your git skills should easily be good enough to handle that. By the w…
Backups can be made independent of source control.
> What about making smaller commits and going back and editing it later?
In experience, it's actually more time consuming to restructure an existing set of commits (especially if they're making changes to the same files and same lines of code) compared to just making a new set of commits.
> By the way, you know about 'git add -p', right?
I am aware of it, but I'm not a fan of the menu based approach. When I stage code with git apply, I actually use vim's feature of visually highlighting the part of the diff I want to stage and filtering those lines through the git apply command. I can skip things like debug statements I've added to the code when staging. I can also unstage code by using the same command with the -R parameter.
I even commit within vim by reading the output of git status -v, writing my commit message and filtering that message through git commit with the -F parameter to have it read from standard input.