Custom Git Aliases for More Command Line Productivity

1. Why aliases pay off in everyday developer work

A single git status or git checkout costs barely any time on its own, yet across a workday with hundreds of Git invocations, even a small reduction adds up noticeably. The effect is even bigger for commands with many options, say a specific git log formatting with a graph view and relative timestamps that hardly anyone types out fully from memory without first searching shell history.

Aliases solve exactly this problem by storing a long command once under a short name. Instead of a ten option long line, a two or three letter command is enough afterward, one that quickly becomes muscle memory and keeps standard workflows consistent, since the same, once carefully considered variant of a command gets used every time.

2. Setting up simple aliases via git config

The most direct way to create an alias goes through git config --global alias.name, followed by the actual Git subcommand including any desired default options. Git internally executes an alias defined this way just like a normal subcommand, there is no functional difference between a built in command and a self defined alias, aside from the alias not showing up in the help text.

Such aliases fit particularly well for combinations used repeatedly in identical form, say a compact status output or a log with fixed formatting. Because they are set globally, they are immediately available in every repository on your own machine, without any project specific configuration.

# Compact status output
git config --global alias.st "status -sb"

# Readable log with graph, colors, and relative timestamps
git config --global alias.lg \
  "log --graph --pretty=format:'%C(yellow)%h%Creset %s %C(cyan)(%cr)%Creset %C(green)%an%Creset' --abbrev-commit"

# Quickly amend the last commit without changing the message
git config --global alias.amend "commit --amend --no-edit"

3. Aliases with shell commands using the exclamation mark

A plain alias can only invoke a single Git subcommand. For anything beyond that, say several consecutive commands or external shell tools, the alias is marked as a shell command with a leading exclamation mark. Git then runs the rest of the line directly in the shell rather than interpreting it as another Git subcommand, which lets arbitrarily complex workflows be captured in a single alias.

A commonly used example is an undo alias that reverts the last commit while keeping the changes unstaged in the working tree, a combination built around reset that a plain alias form cannot express, since it needs a specific option combination rather than a pure Git subcommand.

# Undo the last commit, keep the changes
git config --global alias.undo "reset --soft HEAD~1"

# Clean up all merged branches except main and develop
git config --global alias.cleanup \
  "!git branch --merged | grep -v '\\*\\|main\\|develop' | xargs -n 1 git branch -d"

4. Proven aliases for everyday use

Besides status and log formatting, short forms for the most common commands are among the first aliases worth setting up: co for checkout, br for branch, ci for commit. An alias listing recently changed files in the working tree, or one showing commits not yet pushed, also regularly saves a look at documentation or shell history.

Particularly useful is an alias comparing the current branch against its upstream and showing how many commits it is ahead or behind, information that otherwise only becomes visible by combining several commands manually.

git config --global alias.co "checkout"
git config --global alias.br "branch"
git config --global alias.ci "commit"

# Compare the current branch against its upstream
git config --global alias.sync-status \
  "!git rev-list --left-right --count HEAD...@{upstream}"

5. Aliases with parameters via a shell function

Some workflows need a value passed in at call time, say a branch name or a commit count. A pure shell alias with an exclamation mark automatically receives passed arguments as $1, $2, and so on, provided the alias is written as an anonymous shell function that gets invoked right at call time.

This technique fits aliases that create a new feature branch following a fixed naming scheme and check it out immediately, or an alias showing the last N commits in a given format, where N is passed in as a parameter.

# Create a feature branch following a naming scheme and switch to it
git config --global alias.feature \
  "!f() { git checkout -b feature/$1; }; f"

# Usage
git feature checkout-optimization

6. Editing the alias section directly in .gitconfig

Instead of setting every alias individually through git config, the global ~/.gitconfig file can also be edited directly with a text editor. There, all aliases collect under a dedicated [alias] section, which is considerably clearer for a larger collection than individual command line invocations and easier to maintain and comment on in an editor.

This direct editing approach fits well for reworking an existing alias collection or carrying it over from another machine, since the whole section can simply be copied and pasted rather than setting every alias again through git config.

[alias]
    st = status -sb
    co = checkout
    br = branch
    ci = commit
    amend = commit --amend --no-edit
    undo = reset --soft HEAD~1
    lg = log --graph --pretty=format:'%C(yellow)%h%Creset %s %C(cyan)(%cr)%Creset %C(green)%an%Creset' --abbrev-commit

7. Distributing aliases across a team

Aliases are a local setting and by default do not travel along with the repository, so every team member would have to set them up individually. A common solution is a central dotfiles repository holding a shared .gitconfig template with the recommended aliases, which can be set up on every new machine via a symlink or an install script.

A cleaner alternative is the include directive in .gitconfig: it pulls in an additional configuration file that can be maintained separately from your personal base config and distributed through a repository, without touching personal settings like name and email address.

# In your personal ~/.gitconfig
[include]
    path = ~/.gitconfig-team-aliases

8. Advanced: custom Git subcommands as external scripts

When a workflow grows complex enough that a one line alias definition becomes hard to read, it is worth stepping up to a real external script. Git automatically recognizes any executable file on the PATH whose name starts with git- as a standalone subcommand, callable without the hyphen, so git-mycommand becomes git mycommand.

This technique fits scripts with several dozen lines of logic, say an automated release script that bumps a version, sets a tag, and pushes, and offers an advantage over a shell alias in that the script can be written, versioned, and tested in any language, just like any other project tooling.

9. Pitfalls: conflicts and portability

An alias carrying the same name as a real Git subcommand overrides it for your own configuration, which quickly causes confusion when the alias behaves differently than expected, or when documentation describes default behavior that has been overridden locally. Names like log, status, or diff should therefore only be overridden deliberately.

Another pitfall is portability across shells: an alias with an exclamation mark relying on typical Bash syntax may not work reliably on Windows without a POSIX compatible shell like Git Bash, and special characters that are fine in Bash sometimes need different escaping inside a .gitconfig file. Anyone distributing aliases across a team should test them once on every operating system in use there.

10. Summary

11. FAQ: Git Aliases at a Glance