With dvcs/git, is a single commit preferred over multiple, small, thematic commits?
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?
3 Solutions collect form web for “With dvcs/git, is a single commit preferred over multiple, small, thematic commits?”
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).
Its preferable to make commits atomic. That is, a commit represents one logical change to the project in question, and can stand alone.
- Easy code inspection
git bisectto work correctly
It can be difficult, and there are many differing views about “the one best workflow”. Where possible it is better to
- separate concerns – use a number of short lived separate branches, one per concern. You can always squash your commit sequence before the final merge and publishing to a more senior branch.
- commit often – smaller steps make it easier to find where mistakes happened and why, and to align merges. Again you can squash after it works.
- use the staging area and
git stashto partition which work you place in each commit.
- Don’t worry too much about minor slip ups. Foresight only happens if you walk backwards..