Git Good workshop

Git is version control software that will help support a productive workflow throughout all stages of development. This article was written by Thomas Lock, Christopher Ross and David Churchill.

Why version control?

Version control aims to solve the problem of keeping code in order in any scope, whether working solo or as a team. There are many different types of version control available, but Git is the most commonly used in industry.

There are several reasons for this: collaboration features, the branch system, clear update messages and explanations of these updates… it’s such important and widely used software that it’ll come pre-installed as standard on most UNIX machines and distributions.

Basic usage

Initialise a repository

Git solves the problem of keeping code by organising it into “commits”. Each commit is a full copy of the current working code and you’re able to go back at any point to review these older versions. In order to get started, we need to initialise a Git repository.

To do this, open the folder where your code is located and type git init in console. This will create a .git file: a folder that contains the configuration for this instance of git as well as all stored versions of code.


You now want to create what’s known as a branch.

A branch is a different staging area. This means that changes you make within a branch only affect that branch. You’ll usually want at least 2: one (the default) called ‘master’ that represents the current stable working version of the code and one (or more!) for moving between development and testing phases.

To set up a new branch from the command line you can type git checkout -b *branchname*. When you want to switch to an existing branch type git checkout *branchname*.


Updates to code are known as “commits” and feature messages that explain what has been done since the last update. These are written in imperative tense ie “add feature” not “added feature”. This makes syntax when dealing with reversions or merge conflicts easier.

To commit to the current working branch you first need to add the modified files to staging. Git offers the ability to add specific files that have been changed or all files at once. To add specific files type git add *filename* or to add all files type git add *.

You’re now ready to commit. Type git commit -m “*message*” to commit. The -m parameter indicates that you’ll be using a message which is contained within quotation marks.

Push / pull / clone

Interaction between remote working environments (such as GitHub or GitLab) can be done through these three commands: git pushgit pull and git clone.

git push sends all commits and updates (such as creating new branches) currently not on the remote server to the remote server.

git pull receives the current version of the repo from the remote server.

Finally, git clone is what allows you to download existing repos from a remote host.

Exercise: let’s collaborate on a story

Let’s put all of the above to use by writing a story together.

You’ll need to set up a GitHub account if you haven’t done so already. GitHub is totally free for University students (and now also totally free for most people. Thanks Microsoft!)

Login to your account and head to the collab-story repo. Press the “Fork” button on the top left side of the screen. This will create a copy of the repo on your account. Find the URL for this repo and copy it.

Now we move to the command line.

Start by typing git clone into the console. This will create a folder “collab-story” and download the repo from GitHub.

Type cd collab-story to enter the repository folder and switch branch to “writing” by using git checkout writing. Modify story.txt adding in whatever you want to continue the story. Then, git add story.txt and git commit -m “updated story”. Finally, git push to send your update to the hosted repo.

Note: You may be asked to enter in some other commands to set your identity and set upstream. These will be clearly outlined for you: rather than explain them myself, take a look at what the software is telling you and try to enter the commands to fix the issues. If you get really stuck feel free to call someone over.

In a web browser head back to your fork of collab-story and press “New pull request”. Make sure you select the “writing” branch for both repos when comparing.

Type whatever you want for the message and comments and press the big green “Create pull request” button.

IT IS DONE!! I’ll be looking to accept these requests as soon as possible so by the end of this session we’ve written a full story together.

Further reading

Note that in a real-world scenario what we just did might cause a lot of problems. When you try to modify something that someone else has just modified you’ll run into what’s known as a merge conflict

These can be tricky to solve, but there are several plugins available that make dealing with them significantly easier. Git is clever in that it tracks each individual character of a document, so if you’ve changed E.G lines 1 – 3 of a file and a colleague has changed lines 5 – 8 of a file you’ll not run into any conflicts.

You’re now ready to go with version control! Let’s move on to using GitHub for Desktop as a visual aid and an easy way of setting up and updating repos.

Click here for a full guide on using more advanced techniques and terminology in the command line.

GitHub Desktop

GitHub is a service that  hosts Git repositories. GitHub desktop aims to make the process of using Git significantly more user-friendly by obfuscating the commands ran beneath the GUI. In order to understand Git properly, it’s important to understand that GitHub is only a hosting platform. GitHub desktop automates commands without teaching you how to use them properly. In a real world work environment, it is highly unlikely that you’d ever use GitHub desktop.  However, it is useful for beginners to get started using Git and offers various tools to make the transition from no version control to full version control easier.

When opening a new project, GitHub desktop can be used to create a new repository. These repositories, once named, can be made either private or public depending on whether you wish others to see your work.

Once the repository is set up, you will then be required to publish it, see figure 2 for what the publish button looks like. Note: It can only be seen when a new repository has been created.

Figure 1. Getting started
Figure 2. Publish branch

From this point, you may find the location of the local repository by pressing the “Show in Explorer” button as seen in figure 3.

Figure 3: Finding the local repository

When items are added to this local repository, they will appear in the changes tab. Once all the desired changes have been made, they can then be sent to GitHub by pressing the commit button found in figure 4, and then the push button, seen in figure 5. This process can be repeated as many times as you want.

Figure 4: Commit

If you have changed your code and it has been committed to GitHub, the history tab as seen in figure 6, can be used to search through all of the changes that have been previously made.

Figure 5: Pushing to GitHub
Figure 6: History Tab

If your changes were later found to be undesired, they can quickly be reverted back at the click of a button by right clicking the commit that you would like to revert back to and selecting “Revert this commit”.  This can be seen in figure 7 and saves countless hours in trying re-implementing what was deleted.

Figure 7: Revert

GitHub’s branching tool seen in figure 8 is also very useful, as allows developers to create an additional environment, where new concept ideas and features can be implemented and tested. The changes that are made on this different branch, will not affect any of the other branches that may exist, meaning developers have the freedom to experiment and commit changes, safely without any fear that it may affect vital code.

Figure 8: GitHub Desktop