Versioning is essential

With popular services such as GitHub, Bitbucket or Beanstalk, I'm still amazed by how many people still don't use versioning these days.
If you ask them why, they usually say something like "Oh, I have backups of my projects on an external hard drive" or "I don't need versioning because I work solo" or even worse, they ask you what version control is.

When I was in college, I heard about version control for the first time but my fellow students didn't seem to be using it. I started reading about Subversion and Git and I must say that I found it very complex and scary at first.

It wasn't until my first job that I really started using versioning (more specifically Subversion) because I was forced to, in a good way that is.
So, there I was, using my command line interface and all those unfamiliar commands. I didn't have a clue what I was doing but I'm glad I learned it that way and not through a GUI. Because of those commands I now actually understand what happens when updating, committing and merging some code or a branch.

A GUI seems more usable at first but I would recommend not to use it, at least not until you're familiar with the commands and know what happens behind the scenes when performing certain actions.

Some time later, we switched to Git and then it got really interesting. Everything I found strange or illogical when using Subversion now fell into place. Creating branches became something even a toddler could do and wasn't a burden anymore. Committing some code did what it was supposed to do and didn't try to push my changes immediately to the remote repository.
In short, if you want to start using version control, Git is the way to go as far as I'm concerned.

But why should you use versioning at all times you wonder? I listed some reasons below, based on my own experiences.


You're working with technology and everyone knows there is a certain fail rate to these things so having clones or other kinds of backups of your system(s) isn't such a bad idea. Sooner or later, you'll need them and curse yourself to death if you didn't create any backups. Having a remote repository somewhere is one way to keep your projects backed up at all times.

Working from different locations

For some people it might be useful to have their code available at several locations, even when they don't have their own device with them. Or suppose the laptop your project is on gets stolen, you can easily fire up another device or buy a new one and continue working on a local clone of your remote repository in a matter of seconds. You're probably thinking "I could've done this with a classic backup from an external hard drive as well" and you're right.

That's why I'll give you another example for this situation: recently I arrived at the office of the client I was working for and exactly at the time I had arrived, I realised that I had forgotten my backpack (including my laptop) at home. Yep, this sucks donkey balls, I can tell you that.

So I was left with two options: return home and get my laptop (or work from home the rest of the day if the client approves) or stay at the office, use a spare device they had laying around and clone my remote repository so that I could continue working. How would you've tackled this situation without your external hard drive or other kind of backup with you, huh?


One of the most important reasons to me is working in a team. Since I work on web projects, I usually work in a team to get things done. This often includes working with multiple people on the same file at the same time. Without versioning this is virtually impossible because you'll be creating conflicts or overriding someone else's code when saving the file.

Yelling across the office that everyone working on that specific file should save and close it immediately so that you could alter it, might've been the way to go in the nineties but now people would consider you an idiot for not using a versioning system.

If you're using something like Git, it will automatically merge the changes for you when you update your local copy of the project. It might still give you some conflicts, but Git is pretty damn good at solving them for you so there's no need to worry.


Another interesting thing you should always keep in mind is that you're working with clients. Clients are normal people like you and me and everyone knows that people sometimes change their minds. There's nothing wrong with that but you better be prepared when a client changes his mind on a feature you implemented before, told you to remove it last week and now gives you a call to put it back in place.

Without version control, this would mean you have to reprogram the whole thing and waste a lot of time doing so. You're right, you might've commented that part of code but let me tell you that's a dirty way of coding. Also, a feature might include changes in several files, so commenting those alterations in several files is just nuts.

Git has several ways of getting previous changes back like reverting to a certain point in time and creating a branch from it to reimplement the feature. Whatever way you choose to get that code back, it won't take you as long as it would to reprogram the feature.


People who code sometimes like to experiment or get crazy ideas on how to do things in a different way. Again versioning is the way to go here because you can create a new branch (e.g. my-crazy-idea) to safely mess around with your code without affecting or breaking something that already worked before. If your crazy ideas were any good and you got the result that you wanted, you can easily merge this branch my-crazy-idea with the one you started from and still be sure that everything will work just fine. Your experimenting could also go wrong. In that case just delete the my-crazy-idea branch and continue working on your original code.

If you're still not convinced to start using version control by now, I've got one last reason: it's just common sense.