Version Control Basics#
Let's pretend we wrote some code. We need to do a few things with it:
- Back it up remotely
- Allow other people to work on independently of me
- Allow everyone's work to be merged into a single copy
- Have an audit log of changes
- Control access to the code
This is only a sub-set of what version control gets us. On top of version control you can do a whole host of things, but we've only got so much time and the basics are good enough for us at this point in time.
As it stands now, all we're doing is storing the code in files on our local hard drive. That's not ideal.
Back the code up remotely#
One thing version control lets us do is push our code from our local system to a remote system. This push would make a copy of the code, giving us two copies. Depending on how the remote system is configured, the code should be copied multiple times remotely and backed up too.
This simple feature on its own would be a better position to be in versus storing everything on your local system and losing it because a hard drive fails.
Version control allows you to keep a remote, save backup of your code.
Allow other people to work on the code#
It's highly unlikely you'll work in an environment with only a single person working on the code. There are most likely going to be multiple people working on it. This means we need a system that can enable this.
A version control system allows other people to download the code you've written (and pushed to a centralised, remote system) so that they can work on it too.
These other programmers can make changes to the code and then push their changes up to the same remote system. That, in turn, allows you to download the changes and continue their work.
Version control lets us cooperate on a single code base.
Merging changes into a single copy#
If multiple people are making changes to the same code, we need a way of keeping a single copy of that code protected so that changes to it are tightly controlled. To make this happen everyone pushes changes to the code into branches which are then merged into a single branch that's kept as a sort of "master" copy.
Another concept that makes this work is the idea of a merge request (or pull request.) This means a programmer can write some code, push it to the remote version control system, and then issue a "merge request" which other programmers can agree to and have the changes to the code "merged" into the master copy.
Version control is a system that allows us to achieve these objectives.
Audit logs of changes#
Another thing we need is the ability to see who made what changes and when. A full audit log is an important part of a version control system.
It's possible someone makes a mistake and something about the changes they've made breaks the customer experience. That's not ideal. Using the audit log, we're able to discover who made the change, what they did and how we can roll it back.
And in fact, version control gives us the ability to undo the changes found inside a "merge request", going back to the previous code quickly and undoing the broken changes.
This is one of the critical features of version control.
Access control#
In a large organisation you're going to have a lot of code to manage. All the code will be in the same version control system (but not always) and spread across different repositories. Not every programmer in the organisation needs access to the same code as every other programmers. That's why we need to be able control access and prevent access to code to those who don't need it.
I've yet to come across a version control system that doesn't have access control systems.
The solution#
We're going to explore solutions that give us everything above: Git and GitHub.
Git is the command line tool we're going to use to version control some code. We'll experiment with some of its simple features, and we'll create a small, simple repository.
Next, we'll look at GitHub, which isn't affiliated with Git. It's a system for remotely hosting Git repositories.