You are currently offline, so some features of this site may not work fully.

Your browser doesn’t support some of the latest CSS features used to build this site.

Read more about my usage of new CSS features.

For those who haven’t used Git before, it’s a pretty awesome tool used for version control, sharing and collaborating code with others.

The Git logo

But that’s not why we’re here.

Git ain’t that scary! I used to be pretty scared of using the command line to interact with git repositories, and as you may have seen from my last post - Command line ain’t scary - I’m pretty into it now.

So here’s a basic guide to the commands to start using Git via the CLi and a few tips too.


All you need to do is download git. Go!

Cloning and Pulling

The first thing you need to do is clone an existing repository - something like this, for example:

git clone

Easy! Who needs that GUI now?

When others have committed code to the repository and you need to grab their amends, pulling their changes down is necessary:

git pull


git pull origin develop

If you’re on a branch named develop, for example.


When developing it’s usually best practise to create a branch to work on, so that code conflicts are minimised and deployment of new features is managed more easily.

Branching ain’t scary - simply hit:

git branch feature

To create the branch and:

git checkout feature

To switch to it.

To delete branches locally (I always forget this one) you just enter:

git branch -D feature

To delete the remote branch at the same time:

git push origin --delete feature

To delete the remote branch:

git push origin :feature

Now do some coding...I’ll wait.

Committing and pushing

Now you’ve made your changes you have to stage them for committing:

git add filename.html


git add -a

To add all changed, unstaged files.

Commit them like so:

git commit -m "Supply your commit message here"

The -m flag signifies a message that you have to supply.

Merges and conflicts

Now merges are a pretty easy concept to grasp, even via the command line but when it comes to conflicts it gets a little scary. Conflicts happen when you and another collaborator have modified the same file.

Git is usually pretty clever at resolving these situations by itself but on the occasion that the same lines of the code have been changed there will be a conflict.

If you’re still using a Git client by this point such as the one of the GitHub clients or SourceTree that’s fine, but you should probably go back to the top and start this post again.

If however you’d like to resolve conflicts the manual way - it’s not that bad!

git merge develop

Where develop is your other local branch.

When you have conflicts, the CLi will tell you which files have conflicts as shown below:

Terminal window showing Git conflicts
Oops, conflicts!

In the file itself there will be markers >>>>>>> / <<<<<<< and a divider ====== showing the conflicting lines of code, a little something like this:

<<<<<<< HEAD
git ain’t scary
git is scary!
>>>>>>> 436cf9e

Where HEAD is the head of the branch on your machine and the hash is the commit being pulled down and conflicted with.

So all you have to do is go into the particular file, pick which block you want to keep and remove the other along with the conflict markers. Then commit the fix!

It may be a little slower than using a GUI or merge tool at first, but it’s dead easy and you’ll get faster with practise.


Cherry picking is essentially merging individual commits between branches.

For example I might want to merge part of another person’s contributions into my master branch but not all of them, or I may want to merge a hotfix from a develop branch into master to deploy, but not the entire code base which could include some features that aren’t ready for deployment.

I used to be apprehensive of cherry-picking as back when I was using visual GUIs for Git source control it was easy, but moving to using the command line it became a strange concept at first, not having anything to see and know what exactly I was cherry-picking across branches.

You’ll need a hash (use the short or long versions) from a git commit in a different branch and the easiest way to get one is to hit git log - more on that in the next section.

Once you have one simply enter the following command to merge the specific changes from that commit into your branch:

git cherry-pick 436cf9e

To cherry pick multiple commits into your branch do so as follows:

git cherry-pick 436cf9e 6bac935

And there you have it, cherry picked!

Git log

As mentioned before, Git log is the easiest way to see a record of what’s been going on in a project.

git log

Simply logs out the commits in order of most recent along with the commit messages.

However, I often use:

git log --graph --all

To show a nice graph of all branches and their commits with extra details. I also have an alias - a shortcut - for this as well which I’ve shared below.

Terminal window showing Git log graph
Ooh pretty graphs!

So that’s pretty much all you need to be up to scratch with using the command line to interact with Git repositories.

And none it of should scare you now, except maybe those horrible conflicts - but you’ll be fine!

Now go forth and Git!

Bonus features

My Git shortcuts, adapted from my post on adding shortcuts to your .bash_profile.

# Adds all unstaged changes
alias ga="git add -A"

# Creates a new branch
alias gb="git branch"

# Kicks off a commit
alias gc="git commit -m"

# Shows current diff status
alias gd="git diff"

# Checks out a branch/file
alias go="git checkout"

# Logs in a pretty graph
alias gl="git log --graph --all"

# Pushes branch
alias gp="git push"

# Shows unstaged changes
alias gs="git status"

# Sets new remote origin url
alias gso="git remote set-url origin"


Git ain’t really that scary, see?

Try it without a GUI for a while using my tips and let me know how you get on.

Look out for a future post on Git Flow, ‘cos right now I still find this concept a little scary!