Make Atomic Git Commits

I agree generally, but one thing the author doesn't mention is that it's important to always update unit tests in the same commit that you make a code change. Otherwise it's a lot harder to bisect

> Rather, it means that you should be able to describe your changes with a single, meaningful message without trying to tack on additional information about some unrelated work that you did. Another way to define an atomic commit is one that can be reverted without any unwanted side effects or regressions, aside from what you’d expect based on its message. If a commit is removed from your git commit history but doing so removes other legitimate changes, then that commit wasn’t atomic.

I _think_ the author means small focused commits? There are no examples, so it's hard to tell. Reverting a commit that some has added tests for later will of course introduce regressions. And removing a commit will always only remove the changes of that commit, I think- what am I missing? Commits need to build, and ideally test, in an atomic unit. I'd rather see changes and the tests that validate these changes in a single commit.

The exhortation to do atomic commits is a good one but slightly impractical; for whatever reason, I just don’t often think “I should commit this change” during flow state. I did find a semi-practical way of partially implementing atomic commits anyway: rather than git add all, I git add one file and commit, then repeat. It’s not perfect, you do have to review the diff to check for coupled changes (changing a route on the server and the corresponding call on the client, for example), but it’s often possible to “atomicise” your changes into a half dozen commits.