If you use the command-line all day, CLI improvements can add a huge boost to your workflow. One of the simplest ways to improve things is to make your most used commands easier & faster to type, by creating aliases.
But which aliases? Which commands are most important for your usage? You can probably guess a couple, but it's hard to know for sure, and there's plenty you'll miss. Fortunately your CLI history already has all the answers, if you just know how to ask.
As a software developer I'm going to focus on git aliases here, but this applies equally well to any command-line tools you use heavily. I'm also assuming a bash-compatible shell, but the same concept should translate elsewhere easily enough.
The first step is to use
history to do some digging and find out what commands you run most frequently.
history prints every line you've run recently in your shell, in chronological order. That gives us the data we need, and with a little bash-fu we can start to get some answers.
First, what're your most run git commands?
history -n | grep git | sort | uniq -c | sort -k1,1nr -k2
That takes your history, filters for git commands, sorts them alphabetically, counts the repeated lines, and then sorts by the repeat count.
You can add a
| head -n X too, if you'd like to see just the top
X results. For me, with a few weeks history on a new laptop, that looks like:
543 git status 272 git add -p 214 git tree 71 git diff 55 git commit --amend 53 git push origin master 32 git checkout -p 30 git reset 27 git stash pop 26 git stash
That tells you a bunch about my git workflow already! These are all common commands I'm using frequently, and commands I should very seriously consider aliasing.
It doesn't tell the whole story though. How come
git commit --amend is so high up, but
git commit doesn't appear at all?
That's because for many commits I run
git commit -m "..." to commit and pass a message inline, so each of those commands is treated as unique, and won't appear in this top list. We need to get a little smarter.
We can catch cases like that too, by limiting the input we consider for uniqueness. Like so:
history -n | grep git | cut -d' ' -f -3 | sort | uniq -c | sort -k1,1nr -k2
Here I've added
cut -d' ' -f -3, which splits each line by spaces, and includes only the first 3 parts (e.g.
git push origin master becomes
git push origin). This isn't perfect, but it does let us find command prefixes of a given length.
With that, my results become:
543 git status 299 git add -p 214 git tree 199 git commit -m 117 git push origin 71 git diff 60 git commit --amend 34 git checkout -p 30 git reset 29 git diff --cached
We can now see that I'm committing a lot too, but with messages, I'm pushing with many other branches, and I'm diffing my cached (already added) changes often, but usually with an argument ('show me what I've just added to the tests').
Fiddle around with this a little, try a few different lengths of prefix, and you'll quickly find a set of commands that stand out with frequent use patterns, with or without extra arguments.
From there, it's alias time. I could make these aliases within git, but I'd actually prefer to do it at the shell level, so I can shorten them further (not just to
git x but
In my case, I'm doing that by adding the below to my
alias gs=git status alias gap=git add -p alias gt=git tree alias gc=git commit alias gcm=git commit -m alias gca=git commit --amend alias gpo=git push origin alias gd=git diff alias gdc=git diff --cached
(Don't forget to check these don't conflict with anything else you use on your machine!)
These aliases can also be a very convenient place to add any extra arguments you often want but don't always remember, like
diff (ignore whitespace changes) or
git commit (include the diff contents in the commit template, so you can see it while you write your message).
It's a quick trick, but just a little bash magic can tell you a lot about your working habits, and shine a useful light on ways you can make your life easier. Give it a go, and let me know what you think on Twitter or in the comments below.
Originally published on the HTTP Toolkit blog