Git is an incredibly powerful platform for collaboration. The ability to create
light-weight branches as well as push to and pull from multiple remote repos is
the foundation of this power. Learning to harness the
git log command will
help with visualizing all the information that supports these features, refining
and invigorating your current workflows.
Learn Git Branching
Obviously, to take full advantage of the collaborative features of Git, you first have to learn how to use Git branching. There’s an excellent interactive tutorial that instructs by converting the Git commands you run into fancy web animations. If you have a basic understanding of Git but have always wanted to learn about some of its more powerful features, this is the best tutorial out there. For a taste of how it works, there’s also a non-interactive demo that features the animations which make this tutorial so well-designed.
After I ran through this tutorial, I felt for the first time like I really
knew Git. Unfortunately, being a visual learner, I struggled when trying to
apply the same abstractions to actual git repositories. Shortly thereafter, I
discovered that the
git log command actually has features to replicate many of
the same visualizations, but from right within the terminal!
The following is a set of shell aliases that let you run
git log with a
lengthy set of flags culminating in some pretty awesome Git logs. I’m going to
leave a discussion of what the individual flags do to the man pages and just
skip straight to the good part. Feel free to copy and paste these into your
~/.zshrc, or similar file.
1 2 3 4 5 6 7 8 9 10 11
As you can see, there are four aliases, and each does something a little
different. The first,
gl, just shows the graph for the current branch.
shows the graph for all branches, including those which may have diverged from
the current branch. Then there’s a variation on each of these,
glla, which add author information to the logs produced by their
On top of it all, I’ve customized the colors to work especially nicely if you’re
using the Solarized color scheme in your terminal. If you don’t do
anything but copy the above aliases, the only thing that will look different
from the screenshots below is the text between the parentheses, which will
instead all be the same color. To color these the same as below, add this text to
the end of your
1 2 3 4 5
Of course, feel free to tinker with these colors to your liking.
Even when just using
gl, you’ll be able to see all branches that lie further
down on the tree. For example, from the
add_gitignore branch we can see the
origin/gh-pages branch because it’s along the same path in history.
Here we see that multiple branches have diverged from
origin/gh-pages as a
common ancestor, but neither have anything in common with the other, which is
fix_seo_and_readability only showed up once we used
gl above, but with author information!
gll above, but again with author information!
Here are the same four examples, but for the Autolab repo. It’s a little more involved because more people are working on it simultaneously. For projects like this, which have several open pull requests and feature branches, these aliases really shine.
After testing out these aliases on various environments, I discovered that one
of the features I was using in the pretty format (the one that colors remotes
%C(auto)) is not available in older versions of Git. These are
the revised versions of the above aliases that I use on older machines:
1 2 3 4 5 6 7 8 9 10 11
The only real difference is that all the remotes, branches, and tags are blue,
instead of being configurable in you
Jake on the Web
If you cared enough to read that far, you should consider following me on GitHub or paying a visit to my homepage. If this post was about one of my open source projects, make sure to star it on GitHub! I love hearing what people think, so feel free to comment, open an issue, or send me an email.