Why Use Version Control?

Tags: software, software-engineering, developers, tools, techniques, best-practice, classic-mistakes

I see lots of developers hacking away without using version control and this always provokes a face-palm reaction. As far as I am concerned, using version control is the first law of software development. It’s like riding a bike without a crash helmet, or driving a car without wearing a seat belt: you just don’t do it. Not using version control is a classic mistake of software engineering.

However, it also occurs to me that to an inexperienced developer, it might not be clear why this is so. So, I thought I had better make a stab at justifying my opinion on this. So why is version control important?

There are many different types of developer and situations in which they could be developing software. I will simplify this into two main use cases: you are a lone developer, or you are part of a team. This may be an over-simplification but it will suffice for this discussion.

Developing in a Team

Teams are generally better at adopting the right tools but not always. In chapter 3 of his seminal book Rapid Development, Steve McConnel includes lack of automated version control tools in his list of classic mistakes.

I once joined a team of 14 developers working on firmware for business telephone terminals and when I arrived, I found them passing the master copy of the code around to each other on a floppy disk! Management couldn’t understand why the project was behind schedule – they were adding extra developers to try to speed things up (a classic mistake in itself), and the developers were waiting in line to get access to the master copy of the code. When I asked them why they weren’t using version control – and I kid you not – they replied “we are too busy to use version control, we’ll check in the code when it’s done”. A few months later the entire project was canned and everyone was laid off.

I hope the lessons here are obvious. The logistics of sharing a codebase between multiple developers are simply impossible to get right without some sort of version control. The team use-case is not really the one I want to address here though, so I shall move quickly on.

The Lone Developer

Whether in a commercial setting or someone writing software as a hobby, the situation with a lone developer is more interesting. Lone developers often eschew the use of version control, thinking that it will not benefit them. It is just another thing to learn and to get in the way of progress, right?

Duty of Care

First, let me say that if you are developing software in a commercial situation, I think you have a duty of care to your employer, client or customer. In this situation, the version control repository is a business asset. The repository should be on a different computer to where the development is carried out. Basically, if your computer goes up in smoke or you get run over by a bus, your work should survive. There should be no single point of failure. This is perhaps the most important benefit of version control in a commercial setting, but this is not the only benefit.

A Brief History of Time

I used to think version control was all about keeping a history of your software. You never know when this will be important, so it is a useful thing to have, but in general I have hardly ever needed to go back more than a day or two. In some situations, having a detailed history is critical but for the lone developer this is generally not the case. I now regard the keeping of long term history as nice, but not essential. Short term history, though, is very important.

Up Your Game

For me, the most valuable benefit of version control is that it allows me to up my game by using different work flows and techniques. As a result, I am a better and more productive developer.

Modern version control systems have strong support for branching and merging and this can be used to great effect. It enables the use of "work flows" or "branching models" that let you take more control over how you develop and maintain your codebase.

I commit often. Version control is only as good as your last commit. If I write some tests and they pass, I commit. If I write a new class or method and it works, I commit. At the end of the day, I commit.

I always work on a branch. I try to make a new branch for each feature or “thing” I work on, and when that feature or “thing” is complete in some sense, I merge the branch back in. Typically, I will create and merge several branches in a day. Sometimes I create branches off branches.

Have you ever had that experience where you just want to try something out, so you change a few things and it doesn’t really work out? Your code was working but you broke it. Maybe you ran a search-and-replace operation and it had some unexpected results? Can you back out? Can you really remember all the changes you made? Version control helps two ways here.

  1. You can compare with your old version and see exactly what changed.
  2. You can revert to a previous version. If I want to try an experiment, I do it on a branch. If it all goes horribly wrong, I delete the branch and it’s gone and I’m back to where I was with known-good working code.

Armed with this knowledge, you can be confident with experimentation yet never break working code.

I generally have two 'special' branches. I use Git and my master branch contains only releases. I never commit to master unless I'm making a release. Another, called develop is my main integration branch. It is where all my changes ultimately end up. When I start a new feature or bugfix, I create a branch from develop. When that unit of work is complete and tested, I merge it back into develop. This is loosely based on a branching strategy known as 'Git Flow' (see http://nvie.com/posts/a-successful-git-branching-model/) perhaps a subject for another blog post.

Keep it Safe, Keep it Secret

No, I’m not referring to the One Ring. Version control helps you keep your code safe, particularly if you use one of the cloud based systems such as BitBucket or GitHub. Your source code is something you've most likely devoted a lot of time and effort to, probably at least a few hours and more likely weeks or months. Now answer me honestly: do you have a backup? No? Stop what you are doing and commit to version control now.

Cloud based version control doesn't have to be public. If you've used GitHub then you might be forgiven for thinking this, because they want to charge you for a private repository. However, BitBucket doesn't charge to host a private repository as long as you have 10 or fewer users.


I want to address some of the common objections to version control. There has almost always been some sort of open source version control system, but in the last few years the tools that are available have undergone a quiet revolution. If you've looked at version control in the past and rulled it out, then it may be time to take a fresh look. Let’s bust a few myths.

  • Version control tools are expensive

Wrong. They are free. There are many free, open source options to choose from: Git, Mercurial, Subversion, CVS, SMS, etc.

  • I need a server to run it on

Nope. You can host your repository in the cloud, using services such as BitBucket and GitHub. Such services are generally free for individuals and small organisations. BitBucket has a limit of 10 users before you have to pay a subscription and GitHub allows only public repositories for free.

If you do have your own server, then of course you can use it, and you’ll probably be able to find a free product. However, hosting in the cloud has the added benefit of being an automatic off-site backup.

  • If I host my repository in the cloud, I must make it open source

You can, but you don’t have to. All of the cloud providers allow private repositories. BitBucket limits free accounts to having 10 users in a repository while GitHub requires a paid subscription in order to create private repositories.

  • I’m too busy to use version control

You’re just making excuses! You most certainly are too busy to loose all your work and have to re-do it all! Version control, while it has a learning curve, also has GUI tools that make it easy to work with. It is a skill that will pay you back forever.

  • It’s too difficult!

You’re a developer! You can do ANYTHING. Seriously, download Atlassian’s SourceTree and you’re done. It will take you maybe an hour to understand the main concepts.

  • I don’t need it.

You do. You just don’t know it yet because you haven’t lived with it.

Commit. Merge. Push.

Not a ‘shout’ from Skyrim, although it would be fun if it was. “Fus Ro Dah!”

I agree with Steve McConnell. Not using version control is a classic mistake that is completely avoidable at zero cost and very little effort. You never know when you will need it. If you are in a situation that is remotely commercial, you probably have a duty of care to your employer, client or customer. If you are just doing development as a hobby, then you can relatively easily acquire an important skill that will make your life easier and pay dividends forever. What’s the down side?

No Comments

Add a Comment

Let Us Help You

Find us on Facebook