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.

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!

~/.gitconfig

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.

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.

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.

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:

The final two aliases I rely on heavily are for rebasing and pushing 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.

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:

~/.gitconfig

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.

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.

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!

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.