Recently I’ve been thinking about commit sizes and frequency and after several good conversations with my co-workers I decided to write this down.
It seems like some developers are stuck in a mindset that they have to commit large chunks of code all at once (when they’re “done”). Part of this could be due to your VCS, if it doesn’t support local commits (like GIT). The other, more important part, is that tasks aren’t broken down into smaller, more manageable pieces that could be completed independently from one another.
Here’s a good Coding Horror blog that explains what I’m after:
Here’s a few examples of small independent operations that should be committed immediately and separately from other work.
1) Renaming or moving a file.
2) Formatting a file so it’s easier to read.
3) Refactoring a method.
4) Adding a new test method to an existing test class.
If you had to perform each of those steps, plus the actual fix/feature work, I would expect to see 5+ commits for that task. Don’t be afraid to commit more than once, your (D)VCS can handle it.
Smaller changes mean less risk is introduced to the code base, bugs are easier to identify, and code reviews are simplified.