Git Great at Version Control: A Beginner’s Guide to Git and GitHub

Time travel is real.

Okay, consider this: you’ve thought up a brilliant idea for a new game, it’s fresh and experimental, and you dream of it being an “Editors’ Choice”. It’s going okay so far but being bold breaks the game and slowly your motivation. What made this 4th bug? And how do you go back? This is where the Big Blue Box comes in (I love me some Tenth doctor and Rose Tyler). With the highly popular version control system git you can go back through time, create separate playspaces for new features and see all your changes from your first line of code. And collaborate with no fuss or annoying emails! So scrap version11_i_think.js and check out my git basics guide below.

To keep this post relatively short, I’m going to cover the key git commands in this part. Branches, merging and forking will be covered in an upcoming post. Allons-y!

Git great at version control


1 – A little context

2 – Installing git

3 – Initialising your project

4 – Creating checkpoints in space and time

5 – Travelling Back and Forth

6 – So what’s the difference?

7 – Pushing your Changes to the Cloud

8 – Extra Resources

A little context

Git is a local version control tool, tracking changes with each commit you make (checkpoints in space and time that you can go back to during your project). Once you’re ready to “push” your local project to the “cloud”, Github comes in. It’s your git interface, where you can view all your commits, collaborate with other developers and contribute to open-source projects. Without further ado, let’s get it installed!

Installing git

To get git up and running first open your Mac, Lunix or Windows terminal window. (If you’re unfamiliar with the command line here’s my step by step guide.)

The following is a Mac and Linux guide but here are the steps for Windows.

Step One: Install Homebrew (an open-source software that makes installation a breeze) by executing the following command:

$ /usr/bin/ruby -e "$(curl -fsSL"

Step Two: Paste $ brew install git. You can double check this worked by typing: $ git --version. If terminal returns git version *insert number here* you’re all set!


$ git --version
git version 2.13.1

Configuring you settings

Before creating your first git project configure your working environment with git config:

$ git config --global "Your Name"

$ git config --global

NB. To work without entering your password, add your computer as a trusted device by creating a SSH key.

Initialising your project

Now that all the admin’s out of the way let’s create our first git repository (repo). This is where all files and commits are saved. Start by making a new directory (mkdir <directory> ), going inside it (cd <directory>) and typing git init.


$ cd Documents
$ mkdir gitprojects
$ cd gitprojects
$ git init
Initialized empty Git repository in /Users/Jem/Documents/gitprojects/.git/

The folder is now a git repo (note the line “Initialized empty Git repository in /Users/Jem/Documents/gitprojects/.git/).

Next, add a few files with touch <file> and check where you’re at with git status.

$ touch index.html styles.css
$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

Let’s walk through this. We’re on “Initial commit” as we haven’t created our first commit yet. It’s great practice to commit regularly, with every key change.

There are also two “untracked files” as we created an index.html and styles.css but haven’t told git to track them. Let’s do this in the next step.

Creating checkpoints in space and time

Creating commits is a two step process:

  1. git add <file>
  2. git commit -m "Commit message goes here"

We can add any number of files for commit (depending on preference) ie. you may want to add one file at a time. In step one add index.html  (git add index.html) into the “staging area” of “changes to be committed”. This area is the space between your repo and a commit.

$ git add index.html
$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)


On to step two: git commit -m "Commit message goes here".

Note that it is common practice to write your commit messages in the present tense (as a command) e.g. Add index.html. Let’s see this in practice:

$ git commit -m "Add index.html"
[master (root-commit) 2e97a1c] Add index.html
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

Once you’re a few commits in you’ll probably want to check out your previous changes. Cue Big Blue Box.

Travelling Back and Forth

Let’s first set our destination by typing git log. A list of all your commits will appear, sorted by most recent:

commit 74d74ff1a940b7afb33a45e38131a17b9b060309 (HEAD -> master)
Author: Jem <emailaddress>
Date:   Wed Oct 4 10:19:26 2017 +0100

    Add styles.css

commit 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8
Author: Jem <emailaddress>
Date:   Wed Oct 4 10:17:35 2017 +0100

    Add index.html

You can see two commits listed with a long list of numbers and letters after commit. This is your commit id e.g. 74d74ff1a940b7afb33a45e38131a17b9b060309. To travel back to a previous commit add the chosen id to the git checkout command: git checkout2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8.

$ git checkout 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8
Note: checking out '2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 2e97a1c... Add index.html

The above is a little daunting and we’re going to cover HEAD in more detail in the next post. The important part is that we’ve moved to our first commit and successfully travelled back in time. Cool right? To travel back to your most recent commit type git checkout master. Easy peasy.

So what’s the difference?

The git diff command is the beauty and power of version control. Say you come across a bug in your game. Checkout your commits and open each version in the browser. Once you’ve found the bug check the differences between the version with the bug and the next commit to find the culprit.

This command takes two arguments: two commit ids. Let’s add a few changes to gitprojects to see this in practice.

$ git log
commit c23b4aedfb41f553eeaf799191f90b882f91291b (HEAD -> master)
    Add boilerplate and list comment

commit 74d74ff1a940b7afb33a45e38131a17b9b060309
    Add styles.css

commit 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8
    Add index.html
$ git diff 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 c23b4aedfb41f553eeaf799191f90b882f91291b
diff --git a/index.html b/index.html
index e69de29..6505486 100644
--- a/index.html
+++ b/index.html
@@ -0,0 +1,13 @@
+<!DOCTYPE html>
+<html lang="en">
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>Git Great</title>
+  <h1>A Git Great Project</h1>
+  <! --- going to add a list of reasons why git is cool -->
diff --git a/styles.css b/styles.css
new file mode 100644
index 0000000..e69de29

Above you’ll see I added a boilerplate and comment to index.html, commited it, noted the two ids and included them in the git diff command ie.

git diff 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 c23b4aedfb41f553eeaf799191f90b882f91291b

The first argument is the first commit id 2e97a1c1a4309e05ae5eeb1779325c2bfaa3e9d8 (“Add index.html”) and the second is c23b4aedfb41f553eeaf799191f90b882f91291b “Add boilerplate…” . The differences are shown in adds and minuses, with the number of line changes (13). This can save a lot of time in the long run!

Pushing your Changes to the Cloud

When you’re ready to push your local repo to Github (using git push), begin by creating a new repository on GitHub without a (you can add this in later).

Quick side note: “a remote URL is git’s fancy way of saying ‘the place where your code is stored.'” Source

After clicking create repository you’ll see a page include the following. The https link is your remote repository URL.

Version Control - Create Repo on Github Screenshot

To push your local repo onto the remote, first add the remote : git remote add origin <remote repository URL> and then git push -u <remote> <branch>.


$ git remote add origin
$ git push -u origin master

You can verify this worked using git remote -v. Your remote URL should appear after the origin:

$ git remote -v
origin (fetch)
origin (push)

And you’re all hooked up!

We’re just getting started so check out more things git in the next few weeks. See you then!

Version control never felt so good! *Cue Tardis swoosh*

Extra Resources

Udacity Git and Github Course : A brilliant and in-depth course covering git/version control.

Roger Dudler’s Git Cheat Sheet and Git Cheat Cheat: All the git commands you need in one place. Super handy!

Learning version control completely changes your workflow and is an invaluable resource when working alone and as a team. Let me know how it’s going and how it’s helped in the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *