Why Using a VCS Is a No-Brainer

“Oh no!” We’ve all had that moment: You push something live to your store or site and realize something critical is broken; your contact form isn’t sending out emails, users can’t check out, or worse, the site is just dead.

You look around the room to see if anyone noticed the site is down or the beads of sweat bursting from your forehead. Nobody has… yet.

“Don’t panic. Everything will be fine. I can just roll things back.”

In our world at Rocket Code, this is luckily not a common occurrence. But in the rare case it does happen, we’re able to rely on our development process to quickly get things back in working order. One of the most important elements of that process is our use of a version control system, or VCS.

In our projects, we strictly use Git, but most of us have a good working knowledge of other popular systems like Subversion (typically seen as SVN) and Mercurial (typically seen as Hg, mercury’s symbol on the periodic chart). We chose Git because, in addition to the reasons you’ll read about shortly, it scales nicely for a growing team and gives us a bunch of hosting options, plus several of our clients were already using it.

No matter what VCS you choose, though, it’s important to deploy it for any project that requires active development; since the project is being actively worked on, having things like a history of changes and a solid fallback can be extremely helpful.

“But we have fewer than [X] developers. It would just slow them down!”

This is something I’ve heard many times from clients and some companies throughout the years: Tools like Git are just too much work to worry about using in a small shop. Well, in the immortal words of The Dude, “That’s just your opinion, man!”

The benefits of using Git or another VCS are manifold — but allow me to share a few of the most important reasons we use a VCS at Rocket Code, so you can help yourself and others make an informed decision.

Those who cannot remember the past…

If you’re not technically inclined, or have just never used a VCS, then here’s a little primer for you. Regardless of your VCS choice, every time you make a commit (a fancy name for a record of a change to a file), a few things happen. First, the following bits of data are saved: what file or files were changed, the time and date you are committing the change, who made the change, and the actual changes in those files. Also, a unique ID is attached to the commit. When this all gets pushed to your repository (a fancy name for a digital filing cabinet for your code and changes), everyone can see a clear history of what’s been changed by whom and when.

When something goes wrong, your code’s history can help point you to an answer: Oh, you had a contractor come in and do a bit of freelance work for you, and it looks like he or she accidentally made a change to the wrong file aaaaand forgot to undo that change, which is what broke checkout? With a VCS, someone can step in and easily see what was changed — a big first step to a potential solution.

A source of truth

A VCS is a very strong source of truth — and you’re going to need one since that freelancer broke your checkout. Want to know what files were touched when your freelancer stepped in to make changes? Good luck doing that without something like Git or SVN. Steve, Matt and I could have the same file but three different versions of it; with a VCS, you can easily see which file is the original, along with the differences between each person’s file, much more easily than just going line by line.

Having a source of truth is vital to a project, as it gives you something you can always point to and say, “This is what the state of X is.” Now, with content-driven sites, this can get a bit tricky, as your code repository may not contain your latest blog posts. In this case, your code in Git is the source of truth for your structure, and your live site is the source of truth for your content (which still should be backed up somewhere, maybe in a separate repository, but we’ll touch on that later).

This may seem like splitting hairs, but if something happens, having one place to point to that you can say, “This is what will make the site work again,” can save you a ton of time (and money) by not having to dig through your files and hope that what you have is correct and will work.

Project portability

We live and work in an increasingly distributed world. Companies are going to partially or fully remote workforces, our servers aren’t our home computers, and more and more you can do all your work from a fancy mobile device at home or at a coffee shop.

What does this mean for you? Having your project or site stored in a place that can be pulled up virtually anywhere with an Internet connection can be crucial. You may not have a development team locally, but with your code stored in a repository, you can easily hand the keys over to someone who can help, whether they’re in the coffee shop next to you or across the ocean in Australia.

Also along these lines, a VCS lets you make changes and keep a history of those changes even without the Internet, so on the plane you can be happily coding away and be able to have these changes migrated to everyone easily once you reconnect with the world.

It saves your hide

If you couldn’t tell from what I’ve said already, this is probably the biggest piece of why VCS is important for companies big and small: It provides a buffer or fallback for when things go wrong. Or even when things don’t go wrong, like if you or your client had a change of heart about the direction of a page. You can just roll back to the previous body of code and start fresh.

Issues on your project from human error, computer failure and general acts of God just plummet — and the turnaround if one of those things does happen is substantially quicker in most cases.

Not just for code

In a way, VCS is just a fancy form of backup for a body of code. You should back up your vital data regularly and often, so why not give the same amount of consideration to your code, especially when that code can be vital to your success?

Said another way, VCS isn’t just for code. One of my favorites non-code applications for a VCS is for writing. Seeing a clear editorial history, especially with something peer-reviewed, can streamline so many things.

Ultimately, the advantages of having version control, no matter which system you choose, far outweigh any kind of perceived slowdown in process, since the advantages themselves don’t really have any inherent downsides. Having a portable, clear source of truth that includes a history of changes that could save you from human error? Sign me up in a heartbeat. Oh, and did you say that it’s basically free? I’ll take two.

Now, if you’ll excuse me, I need to push my commits for the day.