With dvcs/git, is a single commit preferred over multiple, small, thematic commits?

Question

This may not be a git specific question, but it comes up in the context of git. The idea may apply more broadly to other vcs's.

I am working on a small project in which I am currently the only developer. I'm getting used to using git, so I am wondering about best practices. As I implement new features/functions, I find that I work on multiple files, their examples, and documentation at once, such that my git status may report 15 files that have changed. But those files might relate to 3 different parts of the project.

Is it better to commit them in 3 separate parts, keeping the related files together, so that I could later go back and more easily find those commits. Or it is just as easy to commit them all at once with an appropriate message?

Answer 1

Its preferable to make commits atomic. That is, a commit represents one logical change to the project in question, and can stand alone.

This allows

1. Easy code inspection
2. git bisect to work correctly

Answer 2

One criteria that can help you make the right "amount" of commit is git bisect or git blame: would a large commit be a nuisance when trying to git bisect in order to detect a bug?

That is what describes the "Understanding the Git Workflow" blog post, when it describes "checkpoint commits" (too little commits capturing the code in a unstable state), or "no-ff commits" (which represents too many modification bundled together in one large commit).