Git Aliases to the Rescue

Posted on November 15, 2016 · 5 min read

git  

The more I use Git, the less I believe how I could work without it. Although its usage is widely spread (is there anyone out there using SVN voluntarily?), it's common to start with the basics (fetch, pull, add, commit, push, ...), memorize them as you've been told, and move on.

As with most things in software engineering, you can't use something properly until you have a good grasp of how it works. There's a difference between using Git and using Git.

The best way to start is to dig deeper into the commands you already know by using the --help option:

git <command> --help

You'll soon realize how complex and powerful Git can be, and once you go down that road, there's no coming back.

I'm constantly learning new commands or options, and I try to focus on them one at a time until I start using it automatically. It's also possible that I don't get to that spot, and I end up either dismissing it or, creating an alias to it, hence the subject of this post.

You can define global Git aliases by using the git-config command or writing them directly in the ~/.gitconfig file.

I use Git aliases for two scenarios:

  • shorten the most used commands (for instance, the command I think I use the most is checkout, which I've aliased into co)
  • simplify commands with multiple options

Let's see some examples.

git commit

amend

It's common to amend commits, especially the WIP ones, and I usually don't need to edit the commit message. You can skip the message edition with the --no-edit option, and I use the following alias for that (credit goes to Tim Pettersen):

commend = commit --amend --no-edit

fixup

It's also common while developing to make near-to-atomic commits that you'll eventually fixup. When you do so by rebasing interactively, you have to manually replace all pick commands with fixups. But there's a way to leave a hint on fixups that will eventually happen:

git commit --fixup <commit>

where <commit> is the first commit you'd include in a rebase. You'll end up with a history similar to this:

608601e - fixup! first commit
032d432 - fixup! first commit
c4d1469 - first commit
6ce0a04 - base commit

Then when you run git rebase -i 6ce0a04 the prompt will show:

pick c4d1469 first commit
fixup 032d432 fixup! first commit
fixup 608601e fixup! first commit

I've aliased this into git cf:

cf = commit --fixup

git push

When pushing changes you might need to use the --force option which, by the way, should never be used against shared branches. Instead, the --force-with-lease option will check that your local tree is up-to-day before you can overwrite it (check out this post on Atlassian Developers blog about force-pushing). To simplify its usage I have the following alias (credit goes to Tim Pettersen):

please = push --force-with-lease

git diff

git diff shows the unstaged changes by default, but sometimes you also want to check out the staged changes (git diff --staged), or even all of them at once (git diff HEAD). These are my diff related aliases:

diffs = diff --staged
diffh = diff HEAD

git ls-remote

Sometimes it's useful to list the branches and tags of the remote repository without the need of a UI (i.e. GitHub):

lsrh = ls-remote --heads
lsrt = ls-remote --tags

git stash

This is one of my favorite Git commands. I mainly use it to store work in progress that I'd rather not push yet to the remote repository, when I have to temporarily switch to another branch to fulfill a quick task. I also use it to store local environment-dependent changes in configuration files, which I could easily rewrite if I switched workstations.

The stash is like a stack where you can push your current state to save it for later. You can then apply those changes and either keep them in the stash or choose to discard them.

While saving the state you can attach a description message to identify the changes each stash entry includes, by using git stash save -u "my description message". You can then list the stash content with git stash list. To retrieve changes from the stash, you can apply them using git stash apply stash@{<index>} or apply and remove them from the stash using git stash pop stash@{<index>}, where <index> refers to the position of the set of changes in the stash. This is a really useful command but it can become annoying. Git aliases to the rescue!

sa = "!sh -c \"git stash apply 'stash@{$1}'\" -"
sp = "!sh -c \"git stash pop 'stash@{$1}'\" -"
ss = "!sh -c \"git stash save -u $1\" -"
sl = stash list

More

I use more aliases, especially for git log commands but these are almost mandatory if you want to take advantage of the many customization options it provides. My .gitconfig file is available at GitHub. The template I used to start my own is this one by Albert Serrallé.

References:


Comments

Would you like to leave a comment? Since this blog is hosted on GitHub Pages there's no straightforward way to do so.

Instead, you can add a comment in this GitHub issue. If you'd like to see it here, refresh this page after posting the comment.