Commits to Read Like Your Terminal History
Write commit messages like they are commands for how to modify the code: e.g. Remove file X rather than Removed file X or Removing file X. Leave out distracting words and tense.
git implements commits as the differences between them; it’s designed so that commits are cheap. A series of separate commits that contain isolated and understandable changes is only a bit larger than a single commit - but 10 times more understandable, communicable, reviewable and transposable. So use as many commits as you need for Clean Communication.
Give your commits one job. Don’t “chain commands”; give each command its own commit. Label the type of change.
If you realise there is some other change required to achieve your end goal (e.g. a bugfix, refactor, optimisation, code removal, etc): STOP. Stash your work, and make any prerequisite changes in its own commit.
Illustrate the relationship between commits you create along the way. Share the change early, for faster feedback. (Use the 4 Is of pull requests.)
Apply your stash and resume.
Don’t be concerned if this happens multiple times: you’re actually moving faster, not slower, in the long run. This is normal when Git Gardening.
If you end up with a series of changes bundled into one: Write a list of all the types changes you have ready to commit. Assign a number indicating how independent each change is, or in what order they would need to be applied.
For the first change in your list, stage and commit only the relevant changes.
Stash the remaining changes (so they don’t effect the results) and use your weeders to confirm each commit is valid.
Share your work early for feedback (it’s ok to create a branch per commit); target each pull request to the branch before it, so only the changes in the commit are visible in the diff (smaller fish are easier to swallow).
Un-stash your changes and move to the next commit.