Version control sounds like a big complex topic, and to some degree it is. Though like most things in software I’m sure you already have a great understanding of what version control does. So let’s put on our “hats of pretend time” and start off with a little story:
I have an important paper that I am writing. Things are going great: only 3 more pages to go. Ooop, I just deleted that last paragraph but I didn’t want to do that. Click ‘undo’ and ~whew~ , it’s back.
Tada!’ I just used version control. Undo works in this case by remembering what I did (delete). Because it stored a little bit of history on my paper it can then ‘undo’ that action to get me back to a previous state of my paper (before the delete). The problem with undo is that it is the most simple version control: in most cases it only remembers one thing.
Well that doesn’t seem like a good thing. What if I wanted to see what my paper looked like yesterday? So how do I get around the history limitation? I can save my own history! For example, after every paragraph I write I save off another version of the file–paper_1.txt for the first one, paper_2.txt for the next and so on–so that even if I completely deleted everything I would still have a back up and only lose the paragraph that I was working on.
Now that I have started to build a system I have the ability to save my history. No longer do I have to worry about closing my paper and losing the undo history; it’s all saved elsewhere. I have a way to know what version came before and what came after. I can look back and see how my paper grew as I worked on it. All of these things are now possible because I have access to the history. And really that is all a version control system is: a way to access the history these files. It allows for all sorts of interesting things to all of a sudden become possible because you no longer have to focus on making everything perfect. Having version control is a net that allows you to safely experiment and always have a safe place to land if things go badly.
Lets take this story a bit further. Let’s say that I really didn’t do my research and I soon realize that my entire premise is wrong. The good news is that I only have to edit a few paragraphs but they are all over the place and it could get really messy. I have some really good stuff in here and I want to make sure that I can look back at this version, but how am I going to remember that this is the version of my paper right before I changed direction? Ohh! I can save a copy of my paper and call it paper_wrong_premise.txt and that way I can refer back to it at some later point.
Again, this is a version control concept, it is often called a ‘tag’. All we’ve really done is create a version, though this time we gave it a descriptive name rather then a forgettable number. Now as a human I no longer need to remember was it paper_26.txt or paper_29.txt that I made the change.
And now for something completely different! I’m finding that my paper is kinda dry and boring. It would be way more interesting if I changed the format to be more like a play. This way I can make it a conversation, I can add humor, I can make it interesting. But this is a big drastic change to my paper. Is there a way I could create a new version that I could work from so that I could try out the conversation idea but if I don’t like it I could later just throw only that part away? There sure is! I could make a copy of my paper and call it paper_play_1.txt.
As I’m sure you guessed by now most version control systems have a way to do this too, it’s often called a branch. You can almost think of it like a tag but in reverse. A tag explains what has happened whereas a branch is a way to explain what is about to happen.
So that was fun. I have a much better paper in the conversation format, but in the new format I could never really get page 1 worked out any better than the old boring page 1. So I’ll just leave the conversation paper as page 2 and beyond. I’ll copy in the boring page 1 and save that of as my paper_32.txt (or what ever the next number is) as I want this to now be the main version of the paper that I work from.
In version control speak this is known as a merge, it’s a way for you to collapse the work from one branch on to another branch. In this case I collapsed the work that I did from paper_play onto the main paper branch.
There. I think that the paper is good enough, but it always helps to have some one else look it over. I want to have you read my paper, I want you to be able to make some changes and I want to know what changes you made. I can save this off as paper_to_be_reviewed.txt and email it to you.
This is where version control gets really fun, distribution and sharing. Effectively, what I did here is I created a branch for you to play in. You can make any changes you want and they don’t get in my way. Conceivably I could continue to work on my main paper branch if I wanted to and you can work on the to_be_reviewed version. Later we can merge our changes, or if I really wanted to get picky I could only take part of your changes. It really doesn’t matter because they both have their own little tracks of history.
Ok story time over. Let’s review
Version control is just a system that allows you to keep the history of something. In this example it was my paper, but it can be anything. The version control system will have a way that I can keep this history in order and allow for me to look back in time and see how things grew. This system allows me to play without fear of losing anything. I can experiment and see how it works out. If I like it, I keep it. If it was a complete failure, so what? I just roll back to something that was working. Version control allows me to collaborate with others and reduce the frustration because every change is ideally tracked on it’s own. Version control allows me to play safely and not care about the consequences.