Exploring Git Customization Through Aliases

Many of the tools we use daily seem to have users who either don’t customize anything or attempt to customize nearly everything. I have no desire to convince you that either side of that coin is wrong. After all, knowing the vanilla experience of tools is critical in environments where extras and bleeding-edge features are not permitted. Being aware of how we can apply settings and layers of configurations is similarly critical in that we need to know what we can do with our tools to create a desired outcome. This is nothing new. Without running a survey, I’d say that most people are healthily somewhere between those customization extremes.

When we experience a software annoyance, we’re just a Google (or GPT) search away from finding a solution that either works around those troubles or completely obliterates them. If we’re lucky, the solution is to turn an option on or off. If we’re not lucky, we might need to replace our tools. If we’re exceptionally unlucky (or fortunate enough to identify a business opportunity), we may find that we absolutely must build something new from scratch!

In this article, I’ll share my Git aliases—personal modifications that I’ve found especially useful. I hope it inspires you to play around with customizing your development environment to suit your needs. Feel free to copy them, improve them, or outright ignore them. It’s up to you.

There is no definitive way to get started customizing your development environment. It’s your environment, your tools. I can do little more than provide some examples and say, “Here, you try!” It’s a process of iterative refinement and exploration.

I do not consider myself an expert in using Git, so if something could be better, feel free to share your improvements. I’m open to learning, especially if a new feature handles one of my use cases.

A Few Notes on Setting Up Aliases

Many projects on the Internet are happy to suggest aliases that you configure in your shell. Some will happily supply a bunch of near-cryptic aliases for your shell to source into your environment when you start an interactive session.

I personally don’t like that because it globally squashes many sequences of characters, which could be useful for other things, and because I typically work in a Windows environment. Having my .gitconfig file working across multiple environments is much easier than having command substitutions, shims, and shell aliases all over the place. If you never have to work in a Microsoft operating system, good for you. In keeping things as simple as possible, I just prefer to have a lazy and easily reproducible approach.

Also, only some configurations you want will be something you want at the global or system level. Some things are better suited for the local configurations. There is also the “worktree” concept, which has its own scope for configuration. Full disclosure: I have yet to make use of worktrees with Git, even though it’s been around for a while and sounds like something I would make use of.

In keeping with the simpler approaches, I recommend working with the configuration files directly in a text editor over the one-at-a-time command line entry. The differences in escaping characters interactively for Windows and Unix(-like) systems are not worth the brain power. All it takes is adding the --edit argument, and you’ll be at the correct file for whichever scope you need. The commands I show below are in the global scope for my setup, so you’d likely run git config --global --edit or track down ~/.gitconfig if you wish to add them for yourself.

A Hodgepodge of Aliases

These are by no means all of my aliases. That would be boring and unhelpful. I’m simply suggesting possibilities for your own configurations.

If you happen to keep making the same command typos, consider using an alias as a form of auto-correct:

• It’s easy to put a space between “git” and “k” out of habit. This alias corrects that.
  alias.k = !gitk

For the most part, aliases are used to just make things shorter:

• Verbose branch information
  alias.br = branch -v -v
• Or perhaps you want to fetch updates before getting the branch information
  alias.fb = !git fetch && git br
• Maybe you want to have the diff output a certain way
  alias.dw = diff --ignore-all-space --color-words
• Or maybe you need an alias to list your aliases
  alias.aliases = config --get-regexp alias*

Again, these are just a few suggestions. What really got me to the point of writing about this was a handful of convenience aliases to jump between branches.

Initially, I had some global “set” aliases that would create or update a local alias to check out the current branch. This acted like a bookmark so I could check out another branch for situations where a bug needed to be fixed or a full code review with verification of passing unit tests was necessary.

I ended up having an entry for setbase, setback, and setbug that would let me simply type git base, git back, or git bug respectively, to jump where I needed to go. It works, but I needed a command that worked a level above that to be more versatile. I needed to be able to create the setter aliases that would create the checkout aliases easily. It’s dirty, but it works:

alias.addset = "!git config alias.set$1 \"!f() { git branch --show-current ; }; git config alias.$1 \\\"checkout \\$(f)\\\"\"; git set$1"

With this, you can add a set/checkout combination of aliases for the local repository.

1. git checkout bugfix/bug123 or whatever your “bug” branch is named
2. git addset bug creates “alias.setbug” and “alias.bug”. If “alias.setbug” already exists, git setbug will suffice to update “alias.bug”.
3. Fix the bug, push updates
4. git back (assuming back has been set to whatever branch you were using)
5. Code, commit/stash, whatever
6. git bug will check out the last set “bug” branch again.

It may not be very complicated, but multiple people have asked about my Git commands and inspired me to write about them. I figure this might, in turn, inspire others to experiment with making improvements as well.

Beyond Aliases

If you find that you need something more robust, consider building a shell script or proper program to do your work and give it the prefix git-. If you have an executable in your PATH named git-myprogram Git will call it for you as if it were a built-in command when you type in git myprogram.

It’s a small life improvement that provides some context to the program. Even better, knowing that people will have programs named with the git- prefix will make it easy to search for projects all over the Internet that could help you in your quest to make using Git that much better.

Conclusion

Though I focused on a small set of use cases to customize in Git, I genuinely hope you come away from this article with a desire to find opportunities to replace minor inconveniences with solutions that will save you time and frustration today and in the future.

For further learning, check out other Keyhole Software blogs on Git.