What is version Control?

You aren’t a programmer.  You aren’t any sort of developer at all.  Somebody recommended you put your code under version control.  WTF?

Here is the short, plain English version of what that means.

Version control is a way of tracking
the history of changes to code.

Your website is made up of code.  The page you are looking at, if you click on ‘View Source’ in your browser, is a whole bunch of code.  To understand version control, let’s look at the typical non-controlled system.

  1. Your site lives on a server
  2. You ask your web developer to change something
  3. They download the relevant files via FTP, edit them, and re-upload them
  4. They forget to check the site, and not something is broken
  5. You call them after you notice it three days later because customers are complaining, and they look into it.
  6. Since three days have passed, they forgot where they were, and it takes them a while to find what they were even working on, not to mention fix it.  Meanwhile, your site remains broken.
  7. The developer finally finds it, fixes it, uploads it, checks your site (more thoroughly this time because they are nervous now), and it still doesn’t work.
  8. They tweak it one more time, upload it, and now it works – great!
  9. They get hit by a bus
  10. You hire a new developer and ask them to do one small tweak to that same change the last developer did.  It takes them three days to download all of your code, find the spot you are talking about, do the attempted fix and upload it.
  11. Return to step 4…

or something like that.

Or just recently, this really happened to me and a new client.  They asked me to look at their code.  They gave me FTP access.  I logged on to look around while talking on the phone with them at 10pm.

The next day they called me and told me that their entire registration process had been deleted by me!  Wow – I must have accidentally hit delete, not gotten any sort of confirmation from my FTP client.  Almost lost the client over that late night mistake.

So, that is the problem version control solves.

How does version control solve my problems?

This is how version control works.

Version control works with code repositories.  A code repository is a  cloud hosted version of JUST your code.  Not your site’s images or database, but the code that runs it.  Here is how version control works.

  1. You take your existing site, and push it into a ‘code repository’.  This is basically an exact copy of all of your code as it is right now.
  2. You invite a coder (like me) to work on your code.  You share access to your code repository with me.
  3. I work on the code on my local machine.  When I think I’ve fixed it, I push my changes back to the repository.  They are noted with my name, email, time of change, and the exact changes to the code.
  4. A designated code controller (or just the programmer if you are a small operation) then pushes those changes to a live test site.  This site is on the same server setup and is in every way a clone of your existing site.  If changes work here, they will work live.
  5. On the test site, we notice something not working.  I go back to step 3.
  6. Once the code is tested and working on the test site, we push it to the live site.
  7. IF it doesn’t work on the live site for some huge and mysterious reason, we instantly roll back changes with one click and go back to step 3.  If it does work – we are golden.
  8. I get hit by a bus.
  9. Your new programmer comes in, and can instantly see what lines of code I’ve changed, when I changed them, any notes I left on those changes, etc.  They instantly pick up where I left off.

Then, you NEVER ftp into your website again to make a change.  You have no possibility of deleting things by accident.

This still doesn’t hit your live site.  Then, a controller (usually you’ll have one person in charge of taking code live, but if you cycle through developers anyone with your login information can do it for you) will review the code, make sure it makes sense, and then…

Now, if at any point your code breaks, there is no ‘what did you do’ or ‘oh, a previous developer did that, do you have their contact info?’.  Instead, every change to your code is documented by date, person who made the change, and exactly what changed. If you take code live and even after testing it breaks something, there is a single command you can use to roll back to ANY previous state of your code, so you have very quick mitigation procedures if something goes wrong.

Is there a downside?

The only thing that can make this difficult to implement in a small organization is if you have staff that won’t comply.  Once a site is version controlled, everyone needs to use version control.  The second someone FTPs in and makes a ‘quick change’ things get messy.  The next time a real commit is made, it won’t be able to be taken live as the code bases won’t match.  Then your programmer has a big job on his hand pulling what you did from the live site, merging it into the code base, etc.

In my opinion this trade off is well worth the security you get from having properly secured code.