Commit Early, Commit Often
One of the most important lessons I’ve probably learned over this past week is the mantra that should be drilled into every programmer’s head and then explained:
Commit Early, Commit Often
Even though I’ve been told and heard in the past numerous times that to commit early and commit often is a good thing, I didn’t do a very good job of it in practice. For some reason, I didn’t want to commit anything until I had completed a large portion of code, or a new feature, or fixed not one or two, but many bugs. I basically wanted to build a program / project with as few commits as possible.
I talk about this with respect to version control systems, I think they’re incredibly useful and once you start using them, you’ll never go back to life without them.
Reasons why I thought this was good:
- If I commit now, it might cause conflicts with the other person working on this as well, which will be problematic. I don’t want to screw up my code by updating, so I’ll just finish up a lot and make it work.
BAD: This actually doesn’t make a lot of sense. I wasn’t even able to convince myself of this. There will be conflicts if more than one person is working on the same function in the code or same area. There will be MORE if you commit after a long period of time. If you commit early and commit often, small conflicts will be easy to change and fix as opposed to a huge one.
- I don’t want to look like a bad programmer by submitting things that might not be complete or really neat … I’ll just fix it up later and then commit.
BAD: This is terrible! The only way you can improve is by practicing, and by receiving critique. If you let no one look at your code for fear of judgement and being thought of as inferior, how will you improve? Secondly, just try to learn as much as possible!
- I will commit after I have completed feature x or y, or after I have fixed bugs x, y, z, and q.
BAD: Commit early and commit often! This is in direct violation of that rule! If you wait until you have a big feature or a lot of bugs fixed, it can cause problems! You might lose your data, your files can get corrupted (all worst case scenario things of course, but Murphy’s always waiting to strike!) and then you’ll lose everything you worked for. Commit early and commit often.
- I don’t want to break the build.
GOOD/BAD: It’s excellent to not want to break the build, it’s not good to refuse to commit for large periods of time. Better to test your code out (I’ve heard in Microsoft they test on three different machines with a variety of tests before they add the code to the build).
Reasons that you should always, always always commit early and commit often:
- Your code is not you. Receive feedback, critiques, improve code, do not make same mistake again. Life’s all about that, isn’t it?
- If someone catches a mistake you’re making early on (or even you do), then it’s super easy to rectify in the beginning, as opposed to later in the game. Then it gets 10x harder. I believe there’s a law for this that goes something like:
The amount of effort/difficulty to fix a bug that is found increases 10x for each stage that it is missed in (the stages being requirements, design, implementation, verification, production, and then maintenance).
- If something corrupts, you have a revision that was working pretty close to the one you have right now!
- If you haven’t committed and someone else commits code and then your code breaks after they commit, you can’t really argue their code is the reason for this. It can possibly be the reason, and it is also possible that there was something in your code that is wrong.
- If you make a really stupid delete file or overwrite file mistake, retrieving it is not difficult at all!
That’s all I can think of at the moment, but I hope I’ve convinced or argued enough to help anyone reading this to remember to COMMIT EARLY, COMMIT OFTEN! I learned this the hard way, hopefully my example will be enough to save others!
Saman's Tech Related Musings 
Yes, I definitely agree with this. When i started working I’d have huge portions of uncommitted code because it felt “incomplete” to me. Of course, thankfully I got reprimanded, and I started committing more often. … then it got to a point I thought I was committing too often, so I started committing less. Anyhow, neither of those are problems anymore. Also, another thing, you should only work on one thing at once. Otherwise, you’ll have tons of different files changed, and you might try to selectively commit which could break the build if you can’t remember all the files that you need to commit in order for the code to compile properly. Anyway, ya, I agree. Sushi.
There are elegant solutions for all four of those problems, most of which can be solved with the judicious use of branching. If you focus your development on a feature branch, your code doesn’t have to be pretty or clean or even functional before you commit, only before you merge. Then your workflow becomes “merge early, merge often.”
It’s worth noting that this is the workflow encouraged by distributed VCSs such as Git and Mercurial.
Your style is very unique in comparison to other folks I have read stuff from.
Many thanks for posting when you have the opportunity, Guess I will
just book mark this blog.