When to make a Git Commit (dev.to)

I find Magit mode in Emacs to be very useful to create coherent and concise commits. It has a fabulous interface for picking out the chunks of an edited file that should be staged.

There is really nothing wrong with committing often. For me a unit of work can be fixing a typo. Of course if you share code with others or user CI/CD you might want to commit only working code.

You can always rebase before pushing upstream.

The author is giving out bad advice that's not relevant to Git's mental model. He's using the CVS/SVN old mental model that treated commits as A Really Big Deal instead of embracing Git's new way where commits are merely a savepoint.

Instead, commit to your local private repo whenever you want. Whatever spurious commit you want to make, just do it without thinking. (E.g. "WIP stopping temporarily to go get a soda"). Then use rebase if you want to clean things up.

EDIT ADD: reading the essay again, the author may be restricting his advice to commits on public master. If so, the blog's title should make that distinction prominent because that drastically changes what the "when" in "when to commit" means.

It makes more sense to err on the side of committing too often. When you're ready to submit, use 'git rebase -i' to squash away any silly commits. Done. No blog post needed for this topic.

Even on public repo it makes sense to keep commits small enough in case you need to do a bisect later on.