Ramblings of an aging IT geek
← Ramblings of an aging IT geek
tooling

the git aliases i actually use

A small set of git aliases I keep in every machine's gitconfig, and the reasoning behind the ones that stuck.

A keyboard in front of a terminal

I have collected git aliases for years and thrown most of them away. The ones that survive aren't the clever ones. They're the ones that remove a daily annoyance so completely that I forget I ever typed the long form.

The first is the only log alias worth having:

[alias]
    lg = log --graph --abbrev-commit --decorate \
        --format=format:'%C(bold blue)%h%C(reset) - %C(green)(%ar)%C(reset) %s %C(dim white)<%an>%C(reset)%C(auto)%d%C(reset)'

That is git lg for a readable graph that fits on one line per commit. I run it dozens of times a day and I never run plain git log any more. The dates are relative because "3 days ago" answers the question I actually have, where a full timestamp doesn't.

A scrolling terminal showing source code

After that it's mostly typing reduction:

    co = checkout
    br = branch
    st = status -sb
    ci = commit
    cp = cherry-pick
    unstage = reset HEAD --
    last = log -1 HEAD

The st = status -sb one is quietly the best of these. The short format with branch info is what I want 95% of the time, and the full status output is just noise once you know what you're looking at.

Two that earn their keep more than they look like they should:

    amend = commit --amend --no-edit
    wip = !git add -A && git commit -m wip

amend is for when you've just committed and immediately spotted the typo in the file, not the message. wip is for stashing-by-committing when I need to swap branches in a hurry and a real stash would just get lost. I rebase the wip commit away before anything goes near a pull request, and yes, occasionally I forget and have to explain myself.

The one piece of advice I'd give about aliases is to resist building a domain-specific language out of your gitconfig. I went through a phase of having a git release, a git deploy, a git sync, each one a small shell script hiding three commands. They all rotted. The moment the underlying workflow changed, the alias lied to me, and a lying alias is worse than no alias because you trust it. The plain ones above have needed no maintenance in about five years. That's the whole test: if I'd have to update it when the team changes process, it doesn't go in the gitconfig.

Keep them boring, keep them few, and git lg will pay for the lot.