Deliberating On Software Development

March 6, 2010

When should you commit source code?

Filed under: Uncategorized — Tags: — x97mdr @ 11:52 pm

Are you just starting out with source control?  Have you ever had a hard drive fry with two days worth of work on it? Have you ever tried to merge two branches and had to spend a day working out the kinks?  If so, then hopefully this post is for you!

Tale of woe

There is a tale of woe that is a background to this story.  The version control environment I use is a combination of Subversion on the server with Bazaar locally.  This is sort of an advanced setup but I prefer it because it lets other members of my team who are more comfortable with Subversion to stick with it but lets me use the advanced features of a a Distributed Version Control (DVCS) tool like Bazaar. 

Now one day recently I was working away on a project that had to be done quickly.  I had been working on this project for about 2 days solid, so there was a lost of changes.   I realized at one point that I had modified a file I shouldn’t have and I went to revert this file using Bazaar.  I used TortoiseBzr, right-clicked the file in Windows Explorer, selected only the single file and pressed OK.  I bet you can’t guess what happened next!  For reasons a Bazaar neophyte like myself were unaware of, the entire repository reverted.  Two days of work … gone!  … or so I thought.  After a full-on panic I finally got my head about me and I filed a bug report and got a really fast and informative reply, was able to recover my lost data and move on.  Major kudos to the Bazaar development team here, they were helpful and knowledgeable.  However, this caused me nearly 4 hours of panic-ridden stress … so how could I have avoided this faithful reader?

Commit Early, Commit Often

This mantra is repeated all over the internety-thing here, here and here.  The biggest mistake that programmers make when working with a version control system is waiting long periods of time before checking in their code.  This was the problem that caused me all that stress and it was completely avoidable.  Had I committed at least a few times a day I would have lost at most a few hours work rather than two days worth.  The next obvious question you’re going to ask me is : “What is the smallest chunk to commit”?

What do I commit?

When developers ask me this question I usually tell them something like this: If it relates to a single activity (bug, feature, task), it compiles and it passes unit tests then commit it.  It takes some experience and experimenting to come up with your own formula but I personally find if I make a few classes with their accompanying tests then that’s a unit small enough for me to check in.  This could take 20 minutes or it could take 2 hours but I try to commit at least two to three times per day at a minimum.  I really like the first answer in this stack overflow question where he states that he usually commits a “complete thought”.  It’s fairly abstract again, there is no concrete rule after all, but another possible guidance.


There are a lot of benefits to committing code in small rather than large chunks.  Most of these become apparent when you work with another developer on the same branch.  It is much easier to resolve merge conflicts with another developer in the same branch there the merge conflict is related to just a few files rather than dozens of files.  Additionally, committing in small chunks means that if there are conflicts then you are making the scope of the problem that you have to resolve much smaller.  If you commit 2 dozen files after 4 days there could be several small conflicts that need to be resolved and worked out, all intermingling with each other.  Trust me, this is the stuff of nightmares!  If you commit in penny-packets your merge conflicts will be more coherent and less entangled.

If you use continuous integration to build your project, and you run unit and/or integration tests as part of that build, then you will get even more benefit out of using your version control tool and committing early and often.  The continuous integration system can use unit tests  to make an independent verification that every commit meets a certain set of criteria.  This knowledge can be very comforting to all involved in the project.

You may also find that you develop a rhythm while working this way.  You make a few changes, test them then commit them and watch the build pass.  While I have no data to say that this process makes you more productive, I can say anecdotally that it makes me more productive because I spend less time getting held up by common mistakes.



  1. […] used in conjunction with “Commit early, commit often” Hudson becomes the heartbeat of our team.  Anytime someone performs a commit we get a pile of […]

    Pingback by Why should I continuously integrate? (or … how I learned to love claps and cheers) « Deliberating On Software Development — March 7, 2010 @ 2:38 pm

  2. Your style is very unique in comparison to other people I’ve read
    stuff from. Many thanks for posting when you have the opportunity, Guess
    I will just book mark this web site.

    Comment by webpage — May 25, 2014 @ 3:11 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: