10 levels of Git aliases: Beginner to intermediate concepts

Did you know that Git can be customized to your needs in a multitude of ways?

Creating aliases in Git is a powerful feature that allows you to define "shortcuts" for longer Git commands (and more). For some, it’s just a tool to make command-line Git usage survivable, but I will show you that Git aliases are so powerful they can contribute to making command-line the preferred and most efficient way to use Git.

The main motivation for creating Git aliases could be one or more of the following:

• Optimize: Create shortcuts for frequent Git commands.
• Customize: Make Git behave how you want or support team-agreed habits.
• Memorize: Easy-to-remember shortcuts for complex operations.

In part one of my blog series, I will take you on a journey from the very humble basics, introducing Git aliases that just save typing longer commands, up to more advanced features that even many seasoned Git veterans have never used.

Part two continues on from there, introducing even more advanced concepts and venturing into truly “out there” uses of Git aliases, including some downright crazy examples, before discussing alternatives for solving the same needs.

Learning and understanding these techniques, whether used for aliases you steal from others or venturing into pushing the boundaries yourself, will make you a more efficient and powerful Git user and hopefully make your day-to-day life with Git more enjoyable. Along the way, you will probably also learn a few tips and tricks and explore corners of Git that you weren’t even aware of.

What are Git aliases, and how do we set them up?

Git aliases are substitutions for Git subcommands in the same way that, e.g., Bash aliases are substitutions for other Bash commands or scripts. Git simply allows you to define your own Git commands that do what you want and can be used seamlessly along with the built-in commands.

Aliases are defined in the Git config hierarchy, but as we usually want them to work everywhere on our machine, the global configuration is their natural home.

You can add aliases either by directly editing your global config file or using the git config command.

To create your first simple alias, just try:

This will add a new line to the [alias] section of your global config file and create the section if it isn't already there. Let's have a look:

For more complex aliases, later on your journey, I suggest that you simply open ~/.gitconfig in your preferred editor and add or modify your aliases directly there.

Level 1: The lazy typer

Ok, let's get started with the first level. I am lazy and simply want to optimize my typing of commands I use hundreds of times a day or to handle common typos I frequently make.

We have already seen the st suggestion above, but here are a few more common examples of simple shortcuts:

For "common typo" style aliases, these are a personal preference. Create aliases for whichever commands your fingers can't type. My personal nemesis is switch, but I have just resolved to always use the short "sw" suggested above instead of creating aliases for all the possible typos I can make in that one word. But here are a few examples for inspiration:

Now, at this time you might already be thinking about which Git commands are your best candidates for aliasing. I came up with an interesting answer years ago. Just like Git, my shell (Bash, Zsh) also supports aliases. So I created the following shell alias in my .bashrc and .zshrc config files:

Some of them might already be existing aliases (here slog, st, and glog), but the others might very well be good candidates for you to "shorten" or to remember using aliases you have already made. The only reason I use "git status" so frequently, despite my "git st" alias, is that I deliver a lot of Git training classes, where I commit myself to using the actual commands.

Level 2: Simple options to avoid typing daily option flags

So, time to move up a notch on the Git alias volume control. Aliases also allow us to add "options" to the Git commands we are aliasing, so let's see how we can utilize that.

The most common use case is creating easy aliases for common variants of Git log output.

E.g.:

Another great suggestion is to use this feature to create those pesky "missing" Git commands that you think should have existed and where you might struggle to remember which exact command and option you have to use to achieve that very common task.

Admittedly, many Git users may have never heard about these Git commands and options, let alone used them. This makes these aliases either useless or a great learning opportunity.

Level 3: Complex arguments help us remember rarely-used commands

The next level on our journey is to investigate using aliases for commands that also take complex arguments.

So far, we have mainly focused on aliasing frequently or commonly used commands, but since we can now shorten much more complex commands, we might also find it useful to go in the other direction and use aliases for:

• Infrequently used hard-to-remember Git tasks.
• Making hard-to-type commands handier.

Together, this allows you to use nice Git features that you might otherwise not bother with.

As you can see, I have described the aliases "inline" in the examples above by using the ability to add # comments in your config file. This is not only to make the example easier, but to strongly suggest that you do this as well in your actual config. It took me way too many years to learn the hard way to do this, and now I have numerous weird aliases and other settings collected that I can't quite remember the purpose of.

Let's look at a few more specific and often-used examples from my collection. This time I will actually show you the results. I will show you a useful diff alias, but first, the "before" view running git diff on a markdown file.

Now let's add an alias:

And use that instead:

This is obviously much cleaner and easier to grasp. It is not the alias itself that is doing the magic; these are built-in features in Git. But the alias makes it useful in my daily life because I can't be bothered to remember to type: git diff -w --word-diff=color --ignore-space-at-eol every time.

Let us define:

The shown snippet covers a range of over 3,000 commits in the Tensorflow repo by just showing the commits that are "labeled" (tags or branch heads).

To close this level off, and lead nicely into the next one, let’s look at what’s probably the most beneficial use of aliases with complex arguments: The ability to create even more customized git log commands that suit your preference by utilizing custom formats. I don't want this to become a tutorial on the actual formatting options, so let's just dive right in, and you will catch the drift. This is all thoroughly documented in the Pretty formats section of git help log.

I present to you, my daily driver:

Level 4: Pretty formats - clean up your aliases with reusability

For this level, let us venture outside the immediate realm of Git aliases, and I will teach you how to use the little-known feature of custom pretty formats to clean up your aliases and vastly improve reusability.

(Actual aliases were much longer but all the same format string).

And many similar ones. This made it really annoying every time I wanted to tweak the format, or coloring, etc.

These days, in more recent versions of Git, aliases may refer to others, so the above can be vastly improved, e.g.:

But it turns out that there is a better option.

(See the above-linked documentation for more coverage).

Way too late in my journey, I discovered that Git allowed me to define my own custom "pretty" formats in Git config, but when I found this feature, it was awesome!

These formats can be defined in the [pretty] section of your config (or git config –global pretty.myformat …..) like this:

Once I have these defined, I can use them at any time when running a Git log command:

This also means that I can rewrite all my weird log aliases to use my own pretty format, and then I have a single place to edit whenever my tastes change.

Another bonus of having these pretty formats defined is that I can also use them "on demand" even when running "in-the-moment" log commands.

Level 5: Prefixes - override Git behavior for specific Git subcommands

For level 5, to round off this part one blog post, we’re going to have a look at a very unknown feature in Git aliases utilizing an also rather unknown feature.

It turns out that Git aliases can send options not only to the Git subcommand but to the git command itself. And if you are thinking, "I didn't know that the Git command had options," you are probably not alone.

One useful and easy-to-explain example is the option to control pagination. By default, Git will pass any output of more than a screenful to less (or other configured pager), and output less than a screenful is printed outright. But Git allows us to override this behavior if desired, e.g.:

Let us see how that could be utilized in an alias.
E.g.:

Another good use of this feature is to use it in conjunction with Git's ability to temporarily override config settings.

In Git, you can use the -c option to override a config value for this single command only, i.e., git -c <config override> <subcommand>.

This can also be used as an alias:

Note: This is different from using git commit --author= as it sets both the author and the committer identity, as seen in the following example:

What’s next in the Git blog post series?

I have taken you through a bit more than the basics of Git aliases. We have seen how they can be incredibly helpful for daily work, commands that we use frequently or commands that we use so rarely that we can't remember them. We have also gone a bit outside the box of normal Git aliases by playing around with options for Git itself (already a feature that most users don't know about).

This is a good place to leave you hanging in anticipation of part two, where we continue with:

1. !non-git commands: More “bang” for the buck.
2. Reusing aliases.
3. Pipelining the action: Chaining unix tools for more action or craziness.
4. Bash functions for the win.
5. Going overboard because limits can only be found by crossing them.
6. Bonus round exploring alternatives to Git aliases.

Go to part two!