What you always wanted to know about the Git Command Line but were too afraid to ask

What you always wanted to know about the Git Command Line but were too afraid to ask

What you always wanted to know... The third in our series of “What you always wanted to know…” blogs. Today Philip Armour, Clearvision Technical Consultant, shares his adventures with the Git Command Line.

A comment I recently overheard in the offices of Clearvision : “The best thing about Git interactive rebase is that graphical Git UIs never get as far as implementing it!”

Although intended humorously (and not actually strictly true!), this does underline a valid point concerning Git: namely that Git is first-and-foremost a command-line tool, and that graphical interfaces still have some degree of catching up to do if they want to match the functionality and power that a knowledgeable user can achieve on the command-line.

Influence of the Command Line on Git

For people like myself with a background using centralised SCM systems with primarily graphical UIs, this Git approach may seem upside-down. The influence of command-line-usage on the design of Git is perhaps part of the reason why Git seems so different and strange when you first encounter it.

One of the main Git contributors and a key maintainer of Git-for-windows, Johannes Schindelin, also recently pointed out that the core functionality of Git is somewhat biased towards the needs of those who have historically contributed most to the Git project: namely Code maintainers. Therefore there are many command options to make life easier when you are integrating dozens of code patches from emails.

It’s clear that Github has been a big factor in opening up Git to a broader user base, as it provides a lot of Git functionality accessible via a nice-looking web interface.

Another relevant factor is the progress that has been made in recent years to implement Git in libraries like libgit2 and JGit. This has helped application developers in Java, Python, Ruby and other platforms incorporate Git, broadening how Git is used. Git plug-ins for IDEs (like Eclipse) are very popular with developers, and this is also recognized by Microsoft, who have committed some of their resources to develop libgit2 for the purpose of integrating Git tools in their Visual Studio environment.

Putting Git functionality to one side, there are other strong and valid arguments for why we need graphical visualisations of Git concepts. For example, there are lots of occasions when visualising the Git commit history (especially in the context of multiple branches) is a real life-saver.

One graphical front-end which is included with most Git installs is gitk. Although not graphically advanced or stylish by today’s standards, it is a very useful tool all the same. Another big pull for graphical UIs (especially for Windows users) is the clarity of a side-by-side diff, since not all users are very comfortable dealing with the unidiff format.

Graphical GUIs and visual tools can also be great for helping us learn and understand how Git works and what it does in a way that no man-page ever could. An excellent example of a this is Learn Git branching.

Having said that, many people argue that the command line remains the best channel for using and learning Git, and personally I am a fan of the command line generally.

Perhaps there is a nostalgia factor: programming on the home computers of the late eighties involved a keyboard and flashing cursor with no mouse or GUIs to be seen. Since then I graduated to the Linux terminal, for which most of the commands surely pre-date even the eighties – but that’s a separate discussion!

(Incidentally, for Linux-users a real bonus of Git-for-Windows is that is comes with Git Bash – a bash shell terminal running on Windows. As well as being able to enter your Git commands, you also have unix commands and utilities such as vi, sed, grep etc to play with.)

So let’s look at some command-line tips and ideas.

Graphics without graphics

I’ve already mentioned the importance of being able to visualise some of the constructs in Git, such as our commit histories, but it is perhaps also worth pointing out that some git commands include an element of basic visualisation without any graphics. Try, for example:

git show-branch

and you may get an output similar to this:


The output above the ---- tells us that we have 4 local branches and that the current branch is called develop (it has a * rather than a !).  Below the  ---- are recent commit messages. To see which of these commits are in a given local branch, you look in the relevant column (below the * or !). In the illustration above for example, the commit entitled [featdev_02] featdev_02: commit 1 is present in both the develop and the featdev_02 branches.

Another good example of command-line ‘graphics’ is when you use the --graph option on a git log to show the branches reachable from your current branch:


Possibly the ultimate in text-based ‘visual’ tools is a neat program called tig (see screenshot below).


It is a fast interactive Git history and status browser which makes the most of split-screens and colours. Tools like this can be really useful for using Git via a remote login without access to a graphical desktop.

Let’s Customize our Commands

One interesting fact about the git command-line is that if I create a new script (for example to run a sequence of git commands on my repository) I can then name it git-

Share on facebook
Share on google
Share on twitter
Share on linkedin

Reader Interactions