Many claps!

I'm particularly big on a huge number of tiny commits, but I do it in a very different way, mainly because I have a battery of git tools I have developed over the years.

I always start work on a private branch, and initially, I use a simple and clear branch name, because I have git rename that I use freely

I literally make a tiny commit any time I make a change and the tests pass, but these commits have automatically generated names, using git infer (sorry, that doc page is a bit broken, that's one of the few that is a bash script).

Here's an example of an inferred commit, from my test repo which I just throw any experimental code into without care.

But those commits never end up in production!

As I am going, I clean my commits into very clearly segmented parts, using git rebase of course, but also my git permute and git adjust (which is like git commit --amend except you can use it on commits that aren't HEAD).

Quite often, I realize some portion of what I am doing can be pulled out into an independent pull request, often one that is "obviously correct" and thus a lot less work for the reviewer.

I am a big believer in a lot of "obviously correct" commits and then a small number of much less obvious commits that actually need careful thought and review.

Oh, and each commit message is a simple English sentence, because you won't be surprised to learn that people read English sentences better than things with tags and punctuation:

Document encoder API
Teach input section about encodings (fix #354)
Add Cohere to models
Test some edge cases in serialization

Finally, I have a command to open GitHub projects from the command line, so I can just type gop (short for git go pull or git go p) and go right to the pull request in my browser.

Everything is about speeding up my workflow, not so I can be sloppy, but precisely so I can take that extra time and do a really good job on manicuring the results.

Thanks again for a thought-provoking article!