Read on Twitter
One key practice I encourage and coach for when joining a new team is splitting changes into small, focused commits. I want to talk about the benefits as I think there are way more than folks realise, not just for code quality, but for productivity, knowledge sharing and more. 
First things first, let's acknowledge the fact that doing this well does require a certain level of tooling knowledge and practice. That means being comfortable selectively staging changes (git add --patch) and revising your working history as you go (git rebase --interactive).
1. It also takes a certain level of discipline to slow down and think about the shape of the work you are about to do. This is actually the first benefit in disguise: Planning the work in terms of small, iterative steps is a useful strategy for making a large problem manageable.
2. Slowing down to figure out how a big problem could be broken down into smaller, digestible pieces can help get over the anxiety of a large/complex task. But it's not always possible to see the whole picture before you start; sometimes you just need to take the first step.
You might not see the whole picture yet, but you can see a small change that gets you closer. A small, focused commit is the perfect way to "bank" some progress, capture any insight in a commit message that can be referred to later, before continuing to chip away at the problem.
I love banking small changes. It's a bit like reaching a save point in a video game. You feel a sense of progress and have a perfect restart point if you happen to get lost. It also enables you to reset your working memory, freeing brain cycles to tackle the next challenge.
(Aside: @tomstuart talks more about strategies for breaking down big problems in his talk Get Off the Tightrope )
3. Making small, focused changes that you then commit also helps get ahead of bugs and unintended side-effects early. A banked commit is a perfect opportunity to trigger a build and make sure the change hasn't broken something elsewhere.
Spotting and resolving such an issue is much easier when the surface area of the change is small vs a 1000-line Hail Mary commit of unrelated changes where it could be any number of things that caused the problem. Which leads nicely into...
4. You unlock the full power of Git's secret bug-smashing tool: git bisect. I've not had to use it very often, but when I have it's felt like a super-power for finding the source of regressions. bisect is way less effective without atomic commits https://twitter.com/mitchellh/status/1352011054377697281
5. Resolving merge conflicts is easier. This one only dawned on me recently. Perhaps my brain had put it down to just getting better at unpicking a merge conflict when rebasing, but on reflection a large part can be attributed to my commits being smaller and more atomic.
By virtue of the change being small and focused on one thing, you're going to have an easier time figuring out what the delta between the upstream change and the one your commit is trying to apply should actually be.
6. Deleting code and reverting changes will be easier. If each commit does a single thing, it'll be easier to remove that change later if you happen to change your mind, either whilst still working on the feature, or even much later in the future as the software evolves.
As @tef_ebooks put it: Write code that is easy to delete ( https://programmingisterrible.com/post/139222674273/how-to-write-disposable-code-in-large-systems). Focused commits help you do that.
7. Related, focused commits are also easier to pull out and use elsewhere. You've fixed a bug or done a refactoring as part of a larger piece of work. Cherry-pick and ship those commits now to get the benefit whilst also shrinking the size of your WIP. https://twitter.com/tekin/status/1352215564090015745
8. Saving my favourite for last, small focused commits lead to an infinitely better code review process, both for you and the reviewer. The reviewer gets the option to tackle the review in more easily understood commit-sized chunks, making it less likely bugs will be missed.
Their feedback can also be more targeted, and because the changes are in focused commits, chances are you'll have an easier time incorporating that feedback into existing commits (for those of you that don't fall into the anti-rewriting history on an open PR camp).
For an example of what I mean, imagine trying to understand all the changes in this pull request in one go versus viewing the changes commit by commit, with the commit messages as guiding commentary: https://github.com/DFE-Digital/claim-additional-payments-for-teaching/pull/597
There are more reasons beyond the ones I've outlined here (e.g. searching back through an atomic history to understand the why of the changes) but this thread is already long enough. For more on this sort of thing, here are some talks you should watch:
Simplify writing code with deliberate commits by @joelchippindale
Getting more from Git by @alicebartlett
A Branch in Time (a story about revision histories) by yours truly
I also write about this stuff regularly on my blog so stick that in your RSS feed or subscribe for regular reckons on Git and more: https://tekin.co.uk/writing/git/
