Aliasing your Git Commands for Maximum Productivity

This is a little tip for those of you wanting to optimize your developer productivity and reduce the toil around some of the tasks that you’ll perform likely hundreds of times per week.

I tend to spend a lot of time raising pull requests, writing commits or running various git commands in order to get my current working branch in order prior to getting it merged into production.

It can feel a little tedious running git add -p or git add -A followed by git commit -m "blah" and finally either a git push origin main or git rebase -i origin/main depending on what stage of the cycle I’m in.

This is why I like to alias these popular commands in my ~/.gitconfig file in order to remove some of the tedium in my life.

AutoSetupRemote

This is a life saver - it removes the need for you to specify the origin BRANCH in your git push origin main commands and instead allows you to simply do git push. C’est manifique!

[push]
    autoSetupRemote = true

If you do nothing else in this article but this, you’re life will be that little bit nicer. Your mornings will be a little bit easier, your coffee a little bit tastier and your fingers a little less prone to RSI.

Setting Up The Aliases

Ok, now that you’ve done the absolute bare minimum needed to improve your life immeasurably, let’s have a look at how we can double down on these wins.

Let’s start with the basics.

[alias]
    co = checkout

Being able to quickly spin up a new branch with git checkout -b branch-name is typically how I’d start working on a new feature or a bugfix (yes, even on my side projects, no more straight pushes to main ever.)

This alias is lovely as it allows me to do git co -b branch-name - a small saving, but ergonomically feels a little better than the more verbose option.

Next, has to be aliasing git add -p - this command allows me to pick and choose hunks of code (yes, they are called hunks) prior to writing a commit message. This allows me to visually ensure I’ve not left silly things in my commit such as debug log statements such as fmt.Println("I'm here") which can sometimes make it into production.

a = "add -p" 

The only logical follow-up to the above command has to be an alias for git commit. With a little forethought, we’ve ensured that our previous aliases that are hinged around commands that start with C haven’t taken the most obvious candidate for this alias:

c = "commit"

The final two aliases I rely on heavily are for rebasing and pushing with lease:

r = rebase -i origin/main
pwl = push --force-with-lease

These two are really quite nice and when I invariably have to rebase my branch twice due to a final failing acceptance test criteria, or perhaps a tiny typo in my code, it’s nice to be able to quickly run these commands and fixup my branch ready for prime time.

The Full List

Ok, so we’ve covered some of my favorite aliases. I’ve been endeavouring to expanding my own Git-fu knowledge over the past few years and slowly but surely, I’m starting to branch out into more complex topics (I’m not apologizing for my poor humor…).

The full list of aliases I tend to work around are as follows:

[alias]
        acp = !git add -A && git commit -m \"auto commit\" && git push
        co = checkout
        a = "add -p"
        b = branch
        c = commit -S
        cp = cherry-pick
        d = diff
        l = log
        m = merge
        p = push
	    r = rebase -i origin/main
        pwl = push --force-with-lease
[push]
    autoSetupRemote = true

Bonus Tip: Use the GitHub CLI!

Once you’ve hand-crafted your list of git aliases and are running rings around those archaic folk that still rely on the full commands or, god-forbid, user interfaces (shudder). You should also be incorporating the gh CLI into your workflow to really wow your peers.

Note: I have nothing against folk for their preferences around how they interface with Git - if you choose to use a UI, then god-speed. This was merely a poor attempt at a joke!

This can be downloaded either via homebrew (brew install gh) or you can navigate to the https://cli.github.com/ to download it for your workhorse of choice.

This really makes the process of raising new pull requests into GitHub an absolute dawdle.

$ gh pr create
Creating pull request for my-awesome-branch into main in TutorialEdge/tutorialedge.net

? Title A really cool pull request title!
? Body <Received>
? What's next? Continue in browser
Opening github.com/TutorialEdge/tutorialedge.net/compare/main...my-awesome-branch in your browser.

Adding a good .github/pull_request_template.md file into your repository in conjunction with the above and you’ve managed to get a new bugfix or feature up and ready for review in record time!

Wrapping It Up

Whilst these aliases are effectively a new domain-specific language you have to learn, with sensible aliases, you’ll find yourself really quickly committing (again, not sorry) these to memory and using them in anger during your day-to-day.

One further thing I’d recommend doing is capturing the aliases you accumulate over the years in a dotfiles repository in your personal GitHub. I’ve got my own (arguably it is in need of some love) which I keep here: https://github.com/elliotforbes/dotfiles.

I wouldn’t recommend copying this one exactly, but the idea behind it is a great one. If you ever lose your job, or your laptop takes a trip over the rainbow bridge, then you’re not starting from scratch in a new development environment and setting up a new rig will be swift and painless and get you back up and into the zone sooner.