Quick answer: the best Git aliases to add first
The best Git aliases are the ones that remove typing without hiding risk. Start with aliases for status, log, diff, branch, checkout, commit, stash, and safe force push. Avoid destructive shortcuts until you have muscle memory and rollback habits.
If you keep Git aliases inside your dotfiles, pair this guide with Getting Started with Dotfiles and How to Install Dotfiles Safely. You can also browse shell dotfiles, terminal dotfiles, or the dotfiles marketplace to see how other developers organize Git workflow configs.
Beginner Git aliases
Add these to ~/.gitconfig:
[alias]
s = status -sb
d = diff
ds = diff --staged
l = log --oneline --decorate --graph -20
br = branch
co = checkout
cob = checkout -b
cm = commit -m
amend = commit --amend
st = stash
stp = stash pop
These are safe because they mostly read state or wrap common commands. They do not delete branches, rewrite remote history, or reset work without you asking.
Visual example: alias risk ladder
Not all Git aliases deserve the same amount of caution. A good alias file makes the risky actions obvious and keeps destructive commands longer than read-only commands.
| Risk level | Alias examples | Safe habit |
|---|---|---|
| Low | status, diff, log, branch | Make these short and frequent |
| Medium | stash pop, reset --soft, branch cleanup | Keep names descriptive |
| High | force push, hard reset, clean files | Add guardrails and avoid one-letter names |
This is why git s for status is fine, but git nuke for hard reset plus clean is a bad team habit. Fast aliases should be reserved for commands you can run safely many times per day.
Intermediate aliases for daily work
Once the basics feel natural, add aliases that support review and cleanup:
[alias]
changed = diff --name-only
staged = diff --staged --name-only
last = log -1 HEAD --stat
unstage = reset HEAD --
uncommit = reset --soft HEAD~1
graph = log --graph --pretty=format:'%C(yellow)%h%Creset %C(cyan)%ad%Creset %Cgreen%d%Creset %s %Cblue[%an]%Creset' --date=short
merged = branch --merged
uncommit is useful because it keeps your changes in the working tree. It is less scary than a hard reset and easier to explain to a teammate.
Advanced aliases with guardrails
Advanced aliases should make dangerous actions clearer, not faster in a reckless way.
[alias]
pf = push --force-with-lease
undo = reset --soft HEAD~1
cleanup-merged = "!git branch --merged main | grep -v '^[ *]*main$' | xargs -r git branch -d"
find = log --all --grep
today = log --since=midnight --author='Your Name' --oneline
who = shortlog -sn
Prefer --force-with-lease over --force. It still rewrites history, but it refuses to overwrite remote work you do not have locally. That one flag prevents a lot of avoidable pain.
Real .gitconfig example with comments
This is a balanced alias block you can adapt into your own dotfiles:
[alias]
s = status -sb
d = diff
ds = diff --staged
l = log --oneline --decorate --graph -20
graph = log --graph --decorate --date=short --pretty=format:'%C(yellow)%h%Creset %Cgreen%d%Creset %s %Cblue[%an]%Creset'
br = branch
co = checkout
cob = checkout -b
unstage = reset HEAD --
uncommit = reset --soft HEAD~1
pf = push --force-with-lease
Notice what is missing: no reset --hard shortcut, no clean -fd shortcut, and no branch deletion hidden behind a cute name. Those commands can still be useful, but they should be intentional enough to type out or wrapped in a script that asks for confirmation.
For team dotfiles, add comments above advanced aliases. Comments are not decoration here; they are safety documentation for the next person who copies the file.
Shell aliases vs Git aliases
Git aliases live in .gitconfig and run after git, like git s. Shell aliases live in .zshrc, .bashrc, or config.fish, and run directly, like gs.
Shell aliases are faster to type:
alias g='git'
alias gs='git status -sb'
alias gd='git diff'
alias gds='git diff --staged'
alias gco='git checkout'
alias gcm='git commit -m'
Git aliases are more portable across shells. A good terminal setup often uses both: shell aliases for the most common commands and Git aliases for commands you want to share across machines.
Checklist before copying Git aliases from dotfiles
- Read every alias before sourcing it.
- Watch for
reset --hard,clean -fd, and branch deletion. - Prefer aliases that show state before changing state.
- Keep destructive aliases long enough to be intentional.
- Test in a throwaway repo first.
- Store Git aliases in version-controlled dotfiles.
- Add comments above any alias that rewrites history.
The best alias file is boring to review. It should make your workflow faster without making your mistakes faster too.
Rollback notes for alias mistakes
Git alias mistakes usually happen in two ways: the alias expands to a command you did not expect, or it makes a dangerous command too easy to run. Keep rollback simple.
git config --global --get-regexp '^alias\\.'
git config --global --unset alias.alias-name
If you are testing aliases from a downloaded dotfiles repo, avoid editing your global config first. Use a temporary repo-level config:
git config alias.s 'status -sb'
git config alias.graph \"log --graph --oneline --decorate -20\"
Repo-level aliases are easier to throw away. Once the set feels good, move only the keepers into your dotfiles. This also helps teams discuss aliases before they become personal muscle memory.
If you accidentally run a history-changing alias, stop and inspect before running more commands:
git status
git reflog -10
The reflog is your recovery map for many local mistakes. Do not panic-type additional resets before checking it.
Naming rules for safer aliases
Alias names shape behavior. Keep safe, frequent commands short and make risky commands descriptive enough to slow you down.
| Alias type | Good naming pattern | Example |
|---|---|---|
| Read-only state | Very short | s, d, l |
| Review helpers | Clear and descriptive | changed, staged, graph |
| Undo helpers | Explicit outcome | uncommit, unstage |
| Remote history changes | Never cute or hidden | push --force-with-lease as pf only if the team agrees |
| Cleanup commands | Long enough to review | cleanup-merged |
This keeps aliases useful in both personal and shared dotfiles. A teammate should be able to guess what an alias does before running it.
FAQ
Are Git aliases safe?
Most read-only aliases are safe. Destructive aliases need care. Anything involving reset --hard, clean, branch deletion, or force pushing should be reviewed and tested before it becomes muscle memory.
Should Git aliases go in .gitconfig or .zshrc?
Use .gitconfig for aliases you want to run as git alias-name. Use .zshrc or .bashrc for very short shell shortcuts like gs or gd.
What is the safest force push alias?
Use push --force-with-lease. It is still a force push, but it checks that the remote branch has not moved since you last fetched.
Can I copy Git aliases from someone else's dotfiles?
Yes, but inspect them first. Git aliases can rewrite history or delete work. Use How to Install Dotfiles Safely before copying an entire shell or Git config.
What aliases should every developer have?
Most developers benefit from aliases for status -sb, diff, diff --staged, compact logs, branch creation, stash, unstage, and safe force push.