Git Alias: Faster Workflows Without Sacrificing Security

A git alias is a shortcut that maps a short name to a longer Git command, and the security lesson is simple: an alias that hides what a command actually does is a liability, no matter how many keystrokes it saves. Almost every developer sets up an alias git config eventually, because typing git status forty times a day is tedious. Aliases are genuinely useful. The trap is that the same mechanism that turns git status into git st can turn a destructive, history-rewriting, or verification-skipping command into an innocent-looking two-letter word you run on reflex.

Two kinds of git alias

There are two places aliases live, and the distinction matters.

Git-native aliases are defined in Git's own config and only affect Git subcommands:

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch

Now git st runs git status. These are stored in ~/.gitconfig and travel with your Git setup.

Shell aliases are defined in your shell (~/.zshrc, ~/.bashrc) and can alias anything, including the git command itself:

alias g='git'
alias gs='git status'
alias gp='git push'

Both are fine in principle. The difference is that shell aliases can rewrite the entire command line, which is more power and therefore more room for a footgun.

A safe git push new branch alias

One of the most common requests is a shortcut for pushing a brand-new branch and setting its upstream, since typing the full --set-upstream origin <branch> every time is annoying. Git's config supports shell expansion in aliases prefixed with !, which lets you build a git push new branch alias:

git config --global alias.pushup '!git push --set-upstream origin $(git rev-parse --abbrev-ref HEAD)'

Now git pushup pushes the current branch and sets its tracking upstream in one step. This is a good alias: it is convenient, and it does exactly what its name implies. Nothing destructive is hidden. That is the standard every alias should meet.

Note the ! prefix runs a shell command, so anything after it executes in your shell. Only put commands you fully understand there, and never paste a !-prefixed alias from an untrusted source without reading it.

Where aliases become a security problem

The danger is not aliases themselves. It is aliases that quietly attach dangerous flags. Consider these, which people really do set up:

# DANGEROUS aliases — do not blindly adopt these
git config --global alias.please 'push --force'
git config --global alias.done '!git add -A && git commit -m "wip" --no-verify'

The first turns a force-push into a friendly word. --force overwrites remote history and can destroy a teammate's commits; --force-with-lease is the safer variant that refuses to clobber work you have not seen. An alias named please gives you no pause before doing something that needs pausing.

The second is worse from a security standpoint. --no-verify skips your pre-commit and commit-msg hooks. Those hooks are often the exact controls that catch leaked secrets, run a linter, or block a bad commit. An alias that routinely bypasses them means your secret-scanning and policy hooks silently stop running, and you will not notice until a credential lands in the repo. If your team relies on hooks as a security gate, an alias with --no-verify in it is a hole punched straight through that gate.

Principles for aliases you can trust

A few rules keep aliases in the "helpful" column:

• Name them honestly. The name should hint at the danger. force-push is fine; please is not. If you alias a force push, make the alias use --force-with-lease and name it so you know what it does.
• Never bake in flags that skip safety. No --no-verify, no --no-gpg-sign, no blanket -f in an everyday alias. If you occasionally need them, type them out so the choice is deliberate.
• Keep read-only and write aliases visually distinct. It is easy to fat-finger a two-letter alias. You want the destructive ones to look and feel different from gs and gd.
• Review aliases you copy. Dotfile repos and blog posts are full of clever aliases. Read what a !-prefixed one actually runs before adopting it, the same way you would review any script.

Audit what you have with:

git config --get-regexp '^alias\.'

Read the list. If any alias hides a force push, a hook bypass, or a hard reset behind a cheerful name, rename it or rewrite it to use the safer variant.

Aliases in shared and CI environments

Personal aliases are one thing; aliases baked into a shared setup or CI are another. A .gitconfig committed to a repo, or a shell rc file provisioned onto every developer's machine, propagates whatever unsafe defaults it contains to everyone. In CI especially, avoid aliasing away verification, and be wary of any provisioning script that sets aliases you did not review. An alias that skips signing or hooks in a pipeline undermines controls the whole team depends on.

Used well, a git alias is one of the cheapest productivity wins in your toolkit. The rule that keeps it safe is the one you can state in a sentence: an alias should make a command shorter, never make a dangerous command look harmless.

FAQ

How do I create a git alias?

For Git subcommands, use git config --global alias.<name> <command>, for example git config --global alias.st status so git st runs git status. For aliasing the git command itself or arbitrary commands, add a shell alias to your ~/.zshrc or ~/.bashrc.

How do I make an alias to push a new branch and set upstream?

Use a shell-expanding Git alias: git config --global alias.pushup '!git push --set-upstream origin $(git rev-parse --abbrev-ref HEAD)'. Then git pushup pushes the current branch and sets its tracking upstream in one step.

Are git aliases a security risk?

Not by themselves. The risk is aliases that hide dangerous flags, like --force (which can destroy remote history) or --no-verify (which skips security hooks such as secret scanning). Those bypass controls silently. Name aliases honestly and keep safety-skipping flags out of everyday ones.

How do I see all my configured git aliases?

Run git config --get-regexp '^alias\.' to list every Git alias. Review the output for anything that hides a force push, a hard reset, or a hook bypass behind a friendly name, and rewrite those to use safer variants like --force-with-lease.