Git Better! Learn Aliases, Settings, Tools, Background

This is the editorial for the SitePoint Java Channel newsletter that we send out every other Friday. Subscribe here!

Chances are you’re using Git at work, at home, and even in the kitchen. (Yes, it has become that popular.) And as ever more people use it, there is a lot of great content out there discussing it. In this week’s editorial I want to share some of the things I found particularly interesting.

Customize Git to Your Needs

First off, every Git post is mandated by Linus himself to list a couple of awesome aliases the author thinks will enlighten their readers. Here are mine (straight from ~.gitconfig):

[alias]
    st = status --branch --short
    wat = log --graph --decorate --oneline -15
    cd = checkout
    patch = add --patch
    unstage = reset HEAD --
    unstage-patch = reset HEAD --patch
    com = commit -m
    amend = commit --amend --no-edit
    follow = log --follow -p

I use git st to get a less cluttered version of the status and git wat to see a colorful, tree-like, and diff-free log output that helps me remember where I was before taking the break. In fact, I use them so often that I have a bash alias g that goes git st; echo ''; git wat -5.

Next up is git cd, which I created because I change branches quite often. Once I’m done making changes I try to convince the world I knew what I was doing, so I go through the files change by change with git patch and create separate commits. If something gets staged that shouldn’t have been, I use git unstage and particularly git unstage-patch to unstage – either all at once or, again, change by change.

Typing git commit -m became too long, so I shortened it to git com and because I often forget new files (git patch doesn’t list them) I created git amend to amend the last commit with the newest changes.

Last on the list is git follow, which shows you all changes pertaining to a particular file. Unfortunately I didn’t find a way to just see the commits without the damn diffs because often times I don’t care about them.

Of course I am not the only one with aliases to use and tips to give. Here are a few others:

If you work with GitHub a lot, you might be interested in getting Git to check out pull requests with something like git checkout pr/999 – here’s how. And this tip allows you to clone git clone gh:<repo>. (On a side note, in October GitHub accidentally exposed data from some private repositories – the incident report is quite interesting.)

A nice tool to visualize how a Git repo evolved over time is Git of Theseus. With it you can stack plots for total line count (right) or code line survival rates.

If you’re interested in statistics like commits per author or per month or even to get a suggestion for a reviewer, give git quick statistics a try.

Also if you write a lot of gitignore files, you may want to use to gitignore.io to do this for you. Then all writing a .gitignore requires is gi intellij,eclipse,gradle > .gitignore.

Usability

Knowing Git is great but learning Git can be tough. Especially for part time users who do not stand to gain from investing a lot of time into learning the inner workings. And unfortunately Git is one of the more leaky abstractions and even simple, every-day use in a collaborative environment requires quite a number of commands and a good understanding of what’s going on.

This is not just one man’s opinion either. MIT computer scientists Santiago Perez De Rosso and Daniel Jackson published papers on the topic, two of which Adrian Colye summarized in his awesome blog the morning paper:

But Git is as it is, so what to do if you do have a problem?

Use Git better

Documentation

Git is pretty documented and good advise on pretty much every question is a dime a dozen if you know how to ask. But there is one source to look out for in particular: the official documentation under git-scm.com, which has two branches.

The first is git-scm.com/docs, which is the reference documentation. To put it mildly, it is not the best resource to get started. Let’s check the git tag reference for example – the description starts as follows:

Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.

Unless -f is given, the named tag must not yet exist.

If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message. Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message.

Yes exactly, WTF?! But while that has also been my reaction it is a little unfair. Being the reference it should be precise and terse, not a didactic stroll through the park. If you’re looking for the latter the free Pro Git book under git-scm.com/book is your friend. It’s article on tagging starts with:

Like most VCSs, Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on).

Better. So if you land on a seemingly incomprehensible site that doesn’t really help you have look at the URL. If it starts with git-scm.com/docs, you may do well to go to git-scm.com/book instead and search for your problem there.

Or, when you’re not in a hurry, you could challenge yourself and see how much sense you can make of the reference. Believe me, every time you do that, you’ll come back with a little more knowledge.

Final Words

If you’re interested to hear from Linus personally, he gave a great talk at Google back in 2007:

That’s it for this week – I hope you have a great time!

so long … Nicolai

PS: Don’t forget to subscribe. :)