Why web developers should use version control

Unfortunately in 2015 it is still the case that not all developers use version control.

At first it can seem like a daunting change and depending what you read it may feel like an unnecessary one.

In this article I want to explain why version control is a must have by highlighting the main benefits I have seen from years of making sure my code is under version control.

What is version control

To quote from the official Git website.

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Even if you haven’t used version control you have almost certainly heard the term “git” or “github” bandied about on the internet.

Git is one of many tools that enable you to version control your files. It is the one I would recommend and it is the one used by The Tomorrow Lab.

Github is an online Git repository – It is a convenient place to store your public or private files.

Several years ago I wrote an introductory guide to Git which goes into more detail on the advantages of using Git over some of the other version control systems out there.

Here are what I consider the biggest benefits of using version control.


Version control gives you an immediate backup of your ideas and your code.

Before if you wanted to work on an experimental change you would have to manually backup files that you may want to go back to at a later date.

With version control you just start making changes – If you aren’t happy with them one quick command will get you back to where you were.

Maybe you want to build out an idea over several days, you can perform what is known as a branch that will let you continue to make tracked changes without effecting the main codebase, then once you are happy you can perform what we call a merge to get your main codebase up to date with what you were working on.

All the while others can be working off the main codebase on branches of their own.


When working on a large project that involves more than one person it is good to have accountability over who has been working on what.

Instead of spending hours working out why a method was written the way it was you can quickly see who wrote the method and have a five minute conversation with them to better understand their thought process.

Better yet, a group of changes in version control is known as a commit and comes with an associated commit message. If the original developer wrote a useful commit message you could see their train of thought immediately.

When something stops working in production being able to immediately know who did what can save time and money.


Version control invites collaboration more than anything else I have seen. If your code is version controlled with Git and on somewhere like Github you can point people to your repository and they can take a copy of it and start improving your project immediately.

Once they have made their changes they can request that you merge them back into your main repository so that others can benefit – you have complete control over what gets accepted and what doesn’t.

This has allowed people who would never have had the guts to work on a big open source project to go in and get their feet dirty.

I have gotten a rush from even submitting something small like a pull-request (a request to update the main repository) for a typo in some documentation that has then been accepted.

For non-public projects the collaboration is just as apparent, team members can seamlessly work on the same project at once without fear of stepping on toes or overwriting work.


In the bad-old-days™ we used FTP for deployment – FTP is great for getting files onto a server, but it isn’t great at keeping track of those files, being too secure or being automated.

Git makes it incredibly simple to deploy your code, especially when hosting companies like Heroku allow you to push to a repository that you have said “When this repository is updated, deploy my code onto the server”.

If you deploy up something that doesn’t work or has broken something, instead of clambering about trying to re-upload older versions of files you can simply deploy from the last revision that you know worked. A revision is a point in time of a Git repository.

Git also has the notion of pre-commits – This is code you can write that will run before anything is allowed to be committed, for example if you use a linter to make sure your JavaScript is up to scratch you can make the linter run and if if fails refuse to accept the changed code.

Time Keeping

This feature isn’t something I ever thought I would find useful about using version control but it has been invaluable.

When someone asks you what feature you were working on three weeks ago you are not going to remember, with some simple Git commands you will be able to see all the changes you made during a given period.

One thing we do at Rumble Labs is add a time to our commit messages, so if we were working on something for an hour we would have in the message t:60 – this automatically logs that time for us under the correct client so we can bill our time accurately.

A call to action

The barrier to entry for version control has never been smaller. The tooling is improving continually as is the amount of guides and documentation.

If you still don’t use version control or know someone who is not using it please take a note to try it on the next project. It will open up an entire new world to you.

If you get stuck you can always ask @thetomorrowlab for some guidance!