One big checkin or several smaller ones?

Question

Yesterday when i checked out the latest version of our internal tool i saw about 30+ new versions. This got me curious since i thought that somebody finally fixed those annoying bugs and added that feature i was waiting for so long... and guess what? None of this happened, someone just thought it would be nice to update some headers and do a minor adjustment of two or three functions. Everything in a separate commit. Great.

This raised a discussion in our team - should this be considered ok, or should we prohibit such "abuse"? Arguably this really could fit in one or two commits, but 30 seems to much. How should this be handled - what is the best practice?

Answer 1

You should be committing any time you make a change and are about to move on to the next one.

You shouldn't commit anything that stops the project from building.

You should be filling in the commit message so people know what changes have been made.

That'll do for me.. I don't assume something has been done unless I see it in the commit message...

Answer 2

Generally I think a commit should relate to one logical task, e.g. fixing bug #103 or adding a new print function. This could be one file or several, that way you can see all changes made for a particular task. It is also easier to roll back the change if necessary.

If each file is checked in one by one, it is not easy to see the changes made for a particular update / task.

Also if multiple tasks are completed in one commit, it is not easy to see what changes belong to which task.

Answer 3

I wouldn't care about the number of commits as each commit keeps project consistency (build will still succeed). This is some internal count that shouldn't bother you. If you want to change something here, better tell people to use some structured commit messages (like "[bugfix]...", "[feature]...", "[minorfix]").

By the way, if you want to know if bugs have been fixed or features have been added, using a bug tracing system is much better than checking commits in a SVN-like tool.