Git aliases are shortcuts you define for longer git commands, and while they make daily work faster they can also quietly hide destructive operations or embed secrets if you set them carelessly. A well-chosen set of git aliases turns a fifteen-character command into two, but the same mechanism that saves keystrokes can mask a --force push or bake a token into your shell history. Setting them up thoughtfully is a small DevSecOps win that pays off every day.
There are two flavors, and the distinction matters for security. Git's own aliases live in ~/.gitconfig and only ever expand to git subcommands. Shell aliases live in your .bashrc or .zshrc and can run arbitrary programs. The second kind is far more powerful and far easier to turn into a footgun.
How git aliases work
A native git alias is defined under the [alias] section of your config. You set them from the command line:
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.last "log -1 HEAD"
After that, git st runs git status. These are safe by design: git only prepends git to the expansion, so an alias cannot become an arbitrary shell command unless you explicitly prefix it with !. That exclamation mark is the dividing line between convenient and dangerous, and we will come back to it.
The aliases actually worth having
The best aliases target commands you type constantly and get wrong occasionally. A few that earn their place:
# a readable one-line graph log
git config --global alias.lg "log --graph --oneline --decorate --all"
# see what you are about to commit
git config --global alias.staged "diff --cached"
# undo the last commit but keep the changes staged
git config --global alias.uncommit "reset --soft HEAD~1"
# show branches sorted by most recent activity
git config --global alias.recent "branch --sort=-committerdate"
Notice uncommit uses --soft, not --hard. This is deliberate. A --soft reset preserves your working changes; a --hard reset discards them permanently. Aliasing a --hard reset to a short, easy-to-fat-finger name is exactly how people lose an afternoon of work. Keep destructive operations verbose and deliberate.
Where git aliases become a security problem
The ! prefix lets a git alias run any shell command. That unlocks genuinely useful things, but it is also where secrets and danger creep in. Consider an alias someone writes to push to a private mirror:
# DON'T: token embedded in a shell alias, now in your config and shell history
git config --global alias.mirror '!git push https://user:ghp_realtokenvalue@github.com/org/repo.git'
That token is now sitting in plaintext in ~/.gitconfig, which frequently gets synced to dotfile repos, backed up, and screen-shared. Credentials belong in a credential helper, never in an alias string. Use git's credential manager instead:
git config --global credential.helper manager
The other trap is aliasing force pushes. git push --force can overwrite a teammate's commits on a shared branch. If you must alias it, alias the safer variant, which refuses to clobber work you have not seen:
# refuses to overwrite remote commits you haven't fetched
git config --global alias.pushf "push --force-with-lease"
--force-with-lease checks that the remote branch is where you last saw it before overwriting. It is the difference between "rewrite my own recent history" and "silently destroy whatever the CI or a colleague just pushed."
Auditing the aliases you already have
Before trusting your setup, list everything defined. Aliases accumulate from tutorials, teammates, and dotfile repos you cloned years ago, and you may be carrying one that force-pushes or curls a script:
# every git alias currently defined
git config --get-regexp '^alias\.'
# shell aliases too — the arbitrary-command ones
alias | grep -i git
Read each one. Any alias with a ! prefix runs a shell command and deserves scrutiny — especially ones that pipe curl output into a shell, contain credentials, or run destructive resets and force pushes. Treat your dotfiles the way you treat application dependencies: something you audit, not something you copy blindly. The same supply-chain instinct behind dependency scanning applies to the shell configuration you inherit from the internet.
A sane starting set
If you are building a config from scratch, keep it small and boring. Alias the read-only, high-frequency commands freely — status, log, diff, branch listing. Alias undo operations only in their non-destructive forms. Never alias a bare push --force, never embed a secret, and be suspicious of any ! alias you did not write yourself. For deeper git and DevSecOps practice, our academy covers secure workflow habits beyond aliases.
FAQ
Are git aliases a security risk?
Native git aliases that only expand to git subcommands are low risk. The danger comes from shell aliases and git aliases with a ! prefix, which run arbitrary commands and can hide destructive operations, embed secrets, or pipe remote scripts into your shell.
How do I list all my git aliases?
Run git config --get-regexp '^alias\.' to see every git alias, and alias | grep -i git to catch shell aliases. Review each one, paying special attention to any that use !, contain credentials, or run force pushes and hard resets.
Should I alias git push --force?
Only as --force-with-lease. A plain --force alias can silently overwrite commits pushed by teammates or CI. --force-with-lease refuses to overwrite remote history you have not fetched, making it the safe default for any force-push shortcut.
Where should git aliases be stored?
Native git aliases live in ~/.gitconfig under the [alias] section, set with git config --global alias.name "command". Never store credentials there — use a credential helper like credential.helper manager so tokens stay out of your config and shell history.