Source Control: The Best Superpower

(Note: Jargon glossary at the end)

Have you ever painted something beautiful, only to ruin it with what you thought was a great idea? Have you ever cooked what seems to be a gourmet meal, only to spoil it after muttering: “I think it needs a little more pepper.” Wouldn’t it be great if you could go back. Turn back the clock. Tell yourself: “No! Salvador was wrong, melting clocks don’t improve everything! Stop! Gordon Ramsay knows what he’s bloody doing when he writes one tablespoon in a recipe!”

If only you could, let’s say, revert it back to before you destroyed it, and with it the remainder of your will to continue.

If only you could create some sort of branch of reality where these experimental ideas could be tried out on your work, without having to commit to the consequences.

If you had the superpower to time-travel, or a time-machine, or a time- turner, or a synonym, then it wouldn’t be a problem, right? You’d just zip back to the moment where the brush was hitting the canvas, the pepper was being taken from the spice-rack, and simply not.

It’d be fantastic wouldn’t it, that power, that opportunity to avoid permanently condemning something which you worked so hard on. Don’t attempt to convince me that you’d even pause for consideration, given this offer.

In which case, I pose a question to you.

Why in the hell would you ignore source control?

When I decide that I don’t need that join table, only to mess up my entire backend, I don’t run around frantically attempting to undo the mess I’ve made. You know what I do? I jump into my Octocat themed time-machine and punch in my coordinates (14382150471decd6c43fca8ed0dfbb5780e274).

I mean look at that little guy, and you’re ignoring him. That puddle on the ground is formed of tears. It’s your fault. I hope you’re happy, you monster.

Okay, I’m going to stop berating you now, let’s fix this problem.

There are a lot of different systems to use when talking about source control, I personally use Git, it’s a super commonly used, accessible, and links in with GitHub. If you haven’t heard of it, GitHub takes your version control to the cloud, allowing others to see your code (or not, if you like things private), and letting you pull your work down to different devices, with hundreds of other amazing features for you to explore.

For those of you who have never heard of source control, I will explain. Source control, at its core, is the management of change in your projects, allowing you to save the state of your project at any time; pick and choose which changes you’d like to save; and in more dire cases, revert your changes and return to a previous version of your project (I suppose this is why it is also commonly known as version control).

Using Git as my example, I will walk you through some of the common features of source control and give some examples of when I’d use them.

Let’s say I have a project where I have just finished a major feature, everything is working, but the code is hacky and could be a lot cleaner. Sure, I could start to work on refactoring it straight away, but what if in my haste to improve my work, I break the product. Some may say to use CTRL(CMD)-Z and undo the breaking changes. The problem here is that I’ve been working in over a dozen files, saving changes, deleting code, and I’ve forgotten which files I’ve worked in. This is the perfect situation to use a feature of source control called a commit, and subsequently, a revert.

Instead of the nightmarish hell that I described above, I decide to commit my hacky, working version of my project, allowing me to revert to that version if I break it. A commit acts like a snapshot of a project at any given time, saving all your changes up to that point and allowing you to work on it care-free. Commits stack too, creating a log. This means that you can move as far back as you like through all of your previous commits, giving you a lot of freedom.

A revert is exactly what it sounds like, it is the action of reverting your project back to how it was when a certain commit was, well, committed. This is the bread and butter of source control, and your first real introduction to pseudo-time-travel. Creating a commit is like putting down an anchor in time, allowing you to travel back to that anchor whenever you like. If you had this ability, you’d put down anchors quite often, it’s the same with commits; commit often.

The other concept which I consider key to source control is branching. This time let’s imagine that I’m working on a project along with two other people, all working independently on different features at the same time, possibly in the same file. I personally don’t want to be messing around in a file at the same time as someone else, as our changes might conflict with one another.

The solution to this problem is for everyone working on the project to be working in their own branch. A branch could be considered to be like a parallel universe where only you’re working on the file. When you’re happy with your changes, you essentially compare your universe (the changes in your branch) with what’s in the main universe (the changes in the master file), eventually merging these universes (branches) together. These changes often cause conflicts, as others will probably have entered different code onto the same lines as some of your code. Imagine this like when you merge two universes together, two different people might be standing in the same place, and the universe can’t tell who to put where.

These are called merge conflicts. There is a very easy way to solve these conflicts: rather than merging your branch into the master branch immediately, you first merge the master branch into your own. This gives you a chance to fix all merge conflicts before you start changing the master branch (think, telling the universe where to put the people standing on the same spot before merging). Alternatively, if you don’t like the feature you’ve started to create, and would like to start all over again (or scrap the idea all together), you can delete your branch, knowing that this won’t affect the master branch, or anyone else’s work.

Moral of the story? Don’t try to imitate Salvador Dali? Never mess with Gordon Ramsay’s skills? No: use source control, use Git, and commit often. This is just a brief outline of the basics, please read further, I promise it pays off. Plus, who doesn’t want to learn to time travel?

Jargon Glossary