Version Control is a way for us to keep track of changes in our codebase.
It is heavily used in software development, particularly when large and geographically disparate teams are working on the same codebase.
In layman’s terms, think of Version Control as being sort-of like Dropbox. You can edit, add and delete sections of documents, and Dropbox gives us the power to go back in time and undelete, or in some cases go back to a previous version of that document. Version Control is like that, but way more powerful.
Every time we make a significant change to the code, we ‘commit’ it to the Version Control System, which creates a snapshot of the code at that time and place. We can identify every snapshot of code by its version number, who on the team did it, and when.
Let’s pretend we’re working on a project, and things are working wonderfully. At some point, that wonderful feeling subsides as we realise that we actually broke something in the codebase last week but didn’t notice until now.
Using Version Control, we can:
- Go back in time to when the code was working
- Work out what went wrong
- Fix the bug so the code works again
- Merge that change into the current working copy so we have a solid (and unbroken) codebase again
The beauty of this process is we haven’t lost the previous weeks work that happened after the change that broke things in the first place.
So long as I’m doing regular ‘commits’, then I can take a look at a snapshot from any time throughout the project and see the differences in the code.
We use version control extensively in our longer form workshops, such as Website on a Weekend and the Website Masterclass.
What a Version Control process is like
At its simplest form, as we write code, we do regular ‘commits’ (snapshots), which are stored on our computer. We then ‘push’ those to the central repository, and they are then available to the rest of our team.
We can ‘pull’ code from the central repository, which will then give us the code that our teammates have previously ‘pushed’.
This means that multiple people can be working on the same codebase, and no one’s work will overwrite another’s. It’s *almost* like magic.
Version Control Systems
There are many Version Control Systems (VCS) out there. The most common are Git, Subversion, and Team Foundation Server (TFS).
While Subversion and TFS have their place, Git is by far the industry standard these days. The differences between them all are minimal at a high level, but if you’re unfamiliar with VCS, then Git is definitely the one to know about.
We use Git for all our code at Meeum, and also teach it as part of our longer form workshops.
Within a VCS, you create repositories. Repositories are like folders, or projects, for your workspace.
If you work on a website for XYZ Company, then that will have its own repository (sometimes just called a ‘repo’). If you start a new project for ABC Company, then you would create a new repo for that project.
There are generally no limits to how many repos you can have. I personally have hundreds, as every project I’ve worked on has its own repo. This includes projects started, but yet to be finished.
Version Control Hosting
While we have Git as the tool to move our code around, we need somewhere to store that code that isn’t on our computer.
There are many popular options for this, with GitHub, GitLab and BitBucket arguably being the most popular.
There are pros and cons to all. BitBucket is great for hosting private repos for free, while GitHub is great for hosting and being able to publish repos for free via GitHub Pages. The downside to a free GitHub account is that the contents are public for anyone to view, which in a lot of cases doesn’t matter anyway.
We’ll do a separate article down the track on comparing some of these Git hosting services.
GitHub is the tool we use in our workshops. We’ve previously published an article on how to sign up to GitHub and create your first repository.
Version Control Tools
While Git is the technology we use to move our code around, and places like GitHub or GitLab to store our code, we still need tools to be able to commit, push and pull that code between our computer and whichever Git hosting service we are using.
Some people love using the command line (CMD), while others prefer a tool with a Graphical User Interface (GUI).
There are so many GUI tools out there that it would be impossible to list them all, although the Git website does a pretty good job of listing the most popular.
In all the Meeum workshops that utilise Git, we use the desktop tool created by GitHub, called GitHub Desktop.
GitHub Desktop is very easy to set up and use, and its interface is exactly the same across platforms (Mac & PC). This makes it easy for me to teach with, as every student is seeing the same thing.
Conversely, tools such as SourceTree are overly complicated for beginners and have dissimilar interfaces across platforms so I don’t generally recommend them. The installation process of SourceTree can be a nightmare in a classroom situation too, so I don’t (and never will again) use that particular tool.
We have a previous article on how to install GitHub Desktop.
So there you have it, a brief summary of not only what version control is, but a basic introduction to some of the tools we use with our version control systems.