Most devs know git commit, git push, git stash. Then there's a whole floor below that nobody visits.
Try it yourself:clone[git-archaeology-lab], runbash setup.sh
, and every command in this article has a working exercise waiting for you.
git worktree
— multiple checkouts, one repo
This one is criminally underused. By default, git lets you have exactly one working directory per clone. git worktree
breaks that constraint.
You now have two fully independent working directories — same repo, different branches — with no stashing, no switching, no context loss.
Why it's back: AI coding agents. When you're running Claude Code or Cursor on one branch and need to review a hotfix on another, switching branches mid-session breaks everything. git worktree
lets both live simultaneously. Each agent gets its own tree. No collisions.
git bisect
— binary search your blame
You have a bug. You know it didn't exist three weeks ago. You have 200 commits in between. git bisect
turns that into about 8 tries.
The real power is git bisect run
— pass any command that exits 0 (good) or non-zero (bad). Your whole test suite, a curl health check, a grep — anything that detects the regression works as the oracle. git drives itself to the culpable commit with zero manual steps.
git rerere
— never resolve the same conflict twice
rerere
= Re use Re corded Re solution.
Enable it once globally and forget it's there — until you notice conflicts silently resolving themselves. The payoff is most obvious during long interactive rebases where the same conflict appears across a dozen commits.
git log -S
— the pickaxe You want to know when a specific string was added or removed. Not which commit touched the file — which commit changed this exact text.
-S
searches diff content, not commit messages. It finds commits where the string's count in a file changed — added or removed. Even after a secret is deleted from HEAD, git log -S
finds the commit that introduced it. Deletion isn't enough. Rotate the credential.
git notes
— annotate commits without touching them Commits are immutable. But sometimes you want to attach information to one — a JIRA ticket, a test result, a deployment timestamp — after the fact, without rewriting history.
Notes live in a separate ref (refs/notes/commits
) and don't alter the commit hash. Great for CI/CD pipelines that want to annotate commits with build metadata without touching history.
git range-diff
— diff of diffs
You rebased a branch. You want to verify the rebase didn't silently mangle any patches. git range-diff
compares two sequences of commits patch-by-patch.
=
means the patches are equivalent. !
means something drifted — and git shows you the diff-of-diffs inline. Code review tools don't show you this. Only range-diff
does.
git sparse-checkout
— check out only what you need Mono-repo with 40 packages and you only work in two? Sparse checkout lets you tell git to only materialize specific paths.
Everything else exists in git history but won't appear on disk. Your editor is faster. Your find
commands are sane. In an AI workflow, sparse checkout reduces the surface area your agent sees — fewer files means faster greps, leaner context windows, and no accidental edits to packages you don't own.
git commit --fixup
git rebase --autosquash
You committed, reviewed your own diff, spotted a typo in the third commit back. There's a clean path that doesn't require a painful interactive rebase.
--fixup
is the honest alternative to git commit --amend
. Amend rewrites HEAD; fixup targets any prior commit and leaves an auditable trail until the rebase squashes it.
git blame -C
— follow moved code
Standard git blame
breaks when code moves between files. -C
tells git to detect copied or moved content and attribute it correctly.
Any time you move functions between files, copy-detection blame gives you the true lineage — who decided this logic should work this way, not just who moved it.
git bundle
— the git sneakernet
No network. Air-gapped machine. USB drive. git bundle
packs your entire repo (or a range of commits) into a single file you can carry anywhere.
The bundle is a valid git remote. You can clone from it, fetch from it, inspect it. It's just a file.
Knowing the commands is one thing. Knowing which one to reach for in the moment is another.
The lab repo ships a Claude Code skill file at .claude/skills/git-archaeology.md
. When you open the repo in Claude Code, the skill is available automatically. Describe your problem in plain English — "I need to find when this bug appeared", "I keep resolving the same conflict", "can I have two branches open at once?" — and it reasons through the right command for your specific situation.
To install it in any of your own projects:
mkdir -p .claude/skills
curl -sL https://gist.githubusercontent.com/copyleftdev/c9c12ea89231680d5ef4a68785ecc125/raw/git-archaeology.md \
> .claude/skills/git-archaeology.md
These aren't obscure for obscurity's sake. They were built for problems that are more common now than they were in 2012 — big repos, parallel workstreams, automated agents, compliance trails. The commands existed. The problems caught up.
Want to run every command in this article against real git history?
→ git-archaeology-lab — clone it, run bash setup.sh
, open exercises/
.
Which one did you not know about? Drop it in the comments.
Tags: git productivity devtools ai linux