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
[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
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.
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.
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:
- What’s wrong with Git? A conceptual design analysis
- Purposes, concepts, misfits, and a redesign of Git
But Git is as it is, so what to do if you do have a problem?
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
-vis given to delete, list or verify tags.
-fis given, the named tag must not yet exist.
If one of
-u <keyid>is passed, the command creates a tag object, and requires a tag message. Unless
-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.
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. :)