Git Roadmap
Six stages, each gated by a capability rather than a lesson count. The order is deliberate: the object model first, because every later command — and every recovery — is an operation on it. Memorising commands produces someone who is fine until something goes wrong.
Dependencies that are not optional
Most lessons can be taken in any order within a stage. These four cannot.
- The object model before everything else Every recovery is "point a ref at an object that still exists". Without objects and refs, that sentence is magic rather than mechanism.
- The three trees before any undo command reset, restore and revert differ only in which trees they touch. Learn the trees and the flags stop needing memorisation.
- Rebase mechanics before force-push Force-pushing a branch you cannot explain the rewrite of is how a colleague's commits disappear.
- Commit craft before bisect and blame A bisect that lands on a 2,000-line commit named "fixes" tells you nothing. The investigation is decided months earlier, at commit time.
Stage 1 — The Model
~1hLearn the four ideas every command operates on
A terminal, and a repository you can break. No prior Git knowledge assumed.
- ▸Explain what a distributed model buys, and the one thing Git genuinely cannot do
- ▸Predict what a commit will contain from the state of the three trees
- ▸Walk commit → tree → blob by hash with cat-file, no porcelain commands
- ▸Say why changing one commit changes every commit after it
- ▸Set identity, ignore rules and line-ending policy so nobody else has to fix them
Handed an unfamiliar repository, you can describe its current state — branch, index, working tree, upstream divergence — from `git status` alone, and predict the exact content of the next commit before making it.
Stage 2 — Branching & History
~1.5hShape history deliberately instead of accumulating it
Stage 1, especially objects and refs. Everything here is refs moving.
- ▸Create, switch and delete branches knowing exactly which file changes
- ▸Read a conflict as three versions and resolve for correctness, not for silence
- ▸Choose merge or rebase on whether anyone else holds the commits
- ▸Run an interactive rebase using every verb, including exec
- ▸Pick the right undo — amend, soft, mixed, hard, restore or revert
You take a branch of five messy commits and produce a reviewable series in one interactive rebase — and you can state, for each commit, whether rewriting it is safe.
Stage 3 — Collaboration
~1.5hWork with other people without stepping on them
Stage 2. A rebase you cannot explain is a force-push you should not make.
- ▸Explain why origin/main is a cache, and read any refspec
- ▸Resolve a rejected push without ever typing plain --force
- ▸Structure a change so review is fast rather than polite
- ▸Respond to review with fixups instead of invalidating the reviewer's diff
- ▸Choose a branching strategy from measured branch lifetime
- ▸Cut annotated, signed releases and stamp the commit into the artifact
You can state your team's median branch lifetime from data, name the merge strategy your repository enforces and why, and produce a release whose running binary reports the exact commit that built it.
Stage 4 — Recovery & Forensics
~1hBe the person who stays calm when work disappears
Stages 1–2. Recovery is only obvious once refs and objects are.
- ▸Recover a hard reset, a deleted branch, a bad amend and a detached-HEAD commit
- ▸Name the one category of work Git genuinely cannot recover
- ▸Find when a line appeared or vanished with pickaxe search
- ▸Let an automated bisect name a commit out of a thousand
- ▸Remove a committed secret in the correct order, rotation first
Given "someone force-pushed over main an hour ago", you restore the correct tip from a reflog on any clone and can explain why the objects were never actually gone.
Stage 5 — Scale & Trust
~1hOperate a repository other people depend on
Stage 3 for collaboration, Stage 4 for what can go wrong at scale.
- ▸Put fast feedback in hooks and real enforcement in CI and protection rules
- ▸Share hooks without asking everyone to run a setup script
- ▸Keep a large repository fast with partial clone, sparse checkout and worktrees
- ▸Choose between submodules, subtrees and a monorepo with the costs named
- ▸Prove the author field is unverified, then establish trust with signing and CODEOWNERS
You can forge a commit as a colleague, then demonstrate the exact combination of signing and branch protection that makes that commit unable to reach main.
Stage 6 — Capstone
~1hProve it against a repository you wrecked on purpose
Stages 1–5. The project assumes every one of them.
- ▸Reproduce six real incidents from a script, deterministically
- ▸Recover each one, ending in a verification command rather than an exit code
- ▸Record the recovery time for each, so the real version has a baseline
- ▸Map every incident to a control instead of to "be more careful"
Project — six drills recovered and timed, with a runbook someone who has not read this module could follow at 6pm on a Friday.
Scope, and what changes underneath it
Git's core model has been stable for close to two decades. Its command surface has not — which is why this path teaches the model first and treats the commands as an interface to it.
Where a lesson quotes a default, verify it in your own environment rather than trusting any
document, including this one:
git config --list --show-scope and
git --version settle most disagreements.