My Guide to Git, Part 1


When I first started at my current company I soon discovered there is nothing more dangerous to a codebase than a inexperienced dev with git access keys. On my second day I accidentally deleted my entire days work because of some command.  Of course I have no idea how I did it and I was far too scared to admit it to my boss and so I promptly did the whole days work that night amongst many frenzied google searches and silent prayers that no one in the team would realise the fraud of a developer I was.

Of course – it was fine, after a couple of days I worked out how I had deleted everything and made several notes to never do it again. Which I did. The next day.

Undoubtedly one of the hardest things to get to grips with when you start learning to code is Git. Unlike markup and programming languages, version controlling is not visual. Therefore, if you are unused to working from a programmatic viewpoint, it is incredibly hard to conceptualise. There are tools that can make this easier (git guis – I’ll get onto them in a future post) but even these require a fairly good knowledge of what on earth is going on in order to understand.

In this post – I’m going to take you through the metaphors I developed when I was first trying to get my head go with git, and in the following posts I detail my git toolbox – a nice little dictionary of my favourite git commands.

So what on earth is going on?


So git is a ‘Versioning Control System’, (ohhh, thats some excitingly dull words right there). This basically means that it is a tool that, when you ask it to, makes note of the state of the folder or file you are working on.

So imagine you are playing a computer game – every time you reach a checkpoint, the game saves your progress to that point. That is exactly what git does – except it does more. It keeps a record of every checkpoint you have reached – which means you can go back to that point.

Say you reached a hallway in Hogwarts (yup, we are playing a HP PC game now) and saved the game, you proceeded down the left corridor. This turned out pretty well, you found a Wizard card and a caldron full of beans, but you also found a venomous tentacular and you fainted. So instead you decide to go back to the checkpoint and try the right corridor. This turns out well as you find a stamina boosting chocolate frog – giving you enough life to face the venomous tentacular.

Good that you got that frog - as getting past Peeves here is a bitch
Good that you got that frog – as getting past Peeves here is a bitch

Lets get more complex

So, we have established the idea of these check points (or ‘commits’ as they are really called) and the ability to navigate around them, however, this does not fully appreciate the ‘different version’ bit of version control!

So now lets imagine our file as a tree, with a main trunk of work with regular commits. The trunk is your ‘master’ branch, this includes all the changes are ready and safe to be in your finished website.

But say you want to develop a new part of your website? Maybe a brand new feature.

In this instance your website is a very simple site where you list your favourite people from history. Ah, but then you think: “There are simply not just enough reference to Isabella, the She Wolf of France, on the internet” so you decide to build a hall of fame for the most badass monarchs.

Centuries before Shakira there was Isabella. She was badass.

However, halfway through building your hall you realise that you don’t have a good way to assign images to entries in your website. These are two very different features your website needs, and so they don’t necessarily need to be worked on at the same time.

So – you create two branches from your master tree – a hall_of_fame branch and a better_images branch. You can work on both projects independently, switching between the two easily, then, when they are done – you can merge them into master and push it to live.

The great thing with this branch approach is that you can continue with the general day to day fixes to the site easily. Because the code for these new features is on a seperate branch – you can easily adjust the spelling mistake you made on your last entry (Joan of Arc and John of Arc are very different people) without polluting your codebase with half baked files relating to a hall of fame.

So – got that?

I hear your silence and take it as yes.

Next time – collaborating with branches!


2 thoughts on “My Guide to Git, Part 1

  1. “When I first started at my current company I soon discovered there is nothing more dangerous to a codebase than a inexperienced dev with git access”

    …except an experienced dev with git access

Leave some love!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s