Git & Version Control
Learn the object model first and the rest follows — the three trees, branches as pointers, merge and rebase mechanics, remotes and refspecs, reflog recovery, bisect forensics and repository trust.
Stage 1 — The Model
4 lessonsWhat a distributed model buys you that a centralized one cannot, why Git stores snapshots rather than deltas, and the properties that make branching cheap enough to change how teams work.
Why the staging area exists, what each of the four diff commands actually compares, and how to read git status as a description of three places rather than a list of files.
The four object types, why a commit hash fingerprints all of history, and how every branch, tag and HEAD is just a file containing one hash.
Which config level wins, the settings that prevent whole categories of problem, and how to write commits that are still useful during a bisect three years later.
Stage 2 — Branching & History
4 lessonsWhat creating, switching and deleting a branch actually does to one file, why a fast-forward produces no merge commit, and how to work safely in detached HEAD.
Why a merge needs three versions rather than two, how to read conflict markers as information, and the resolutions that silently lose code.
What rebase actually does to your commits, the interactive todo list in full, and why force-with-lease is the only force-push you should ever type.
The three reset modes mapped onto the three trees, why revert is the only safe undo for pushed work, and what stash quietly leaves behind.
Stage 3 — Collaboration
4 lessonsThe three places a branch name can live, why fetch is always safe and pull sometimes is not, and how reading a refspec makes push behaviour obvious.
What a pull request is in Git terms, the three merge buttons and the histories they produce, and how to structure a change so review is fast rather than polite.
Trunk-based, GitHub flow and GitFlow compared on the only axis that matters — how long a branch lives — plus feature flags, release branches and hotfix paths.
Why annotated tags are the only kind worth shipping, what git describe gives you for free, and how to make a running binary tell you which commit built it.
Stage 4 — Recovery & Forensics
3 lessonsWhy almost nothing committed is ever really lost, how to read the reflog under pressure, and the two situations where recovery genuinely is impossible.
Turning 'it worked last month' into one commit — pickaxe search for when a line appeared, blame that survives refactors, and automated bisect over a thousand commits.
Removing a committed secret in the right order, what filter-repo does that filter-branch should not, and the coordination cost that makes a rewrite a team event.
Stage 5 — Scale & Trust
3 lessonsWhere each hook fires, why client hooks are feedback rather than enforcement, and how to share them without asking every developer to run a setup script.
Why a clone gets slow, the four ways to take less of it, and choosing between submodules, subtrees and a monorepo without regretting it in a year.
Why the author field proves nothing, how SSH signing makes commit provenance a two-line setup, and the branch protection that turns a convention into a control.
Stage 6 — Capstone
1 lessonSix real incidents in one repository — a force-push over main, a committed secret, a lost reset, an unknown regression, a merge that ate code and a duplicated rebase — recovered and timed.
🗺️ Beginner → Expert Roadmap
6 stages with prerequisites and a concrete mastery check at each.
🎯 What You'll Learn
- • Explain any Git command as an operation on objects, refs, the index and the reflog.
- • Walk commit → tree → blob by hash, and say why rewriting one commit rewrites every commit after it.
- • Predict exactly what a commit will contain before you run it, from the state of the three trees.
- • Read a merge conflict as three versions rather than two, and resolve for correctness rather than for silence.
- • Choose between merge and rebase on whether anyone else holds the commits — and force-push safely when you do rebase.
- • Pick the right undo for the situation: amend, soft reset, hard reset, restore or revert.
- • Read a refspec, and explain why origin/main is a cache rather than the branch on the server.
- • Structure a change so review is fast, and respond to review without invalidating the reviewer's diff.
- • Choose a branching strategy from measured branch lifetime rather than from a diagram.
- • Ship annotated, signed tags and make a running artifact report the exact commit that built it.
- • Recover a hard reset, a deleted branch, a bad rebase and a force-pushed branch from the reflog.
- • Turn "it worked last month" into one commit with pickaxe search, blame and an automated bisect.
- • Remove a committed secret in the right order — rotation first, filter-repo second, coordination third.
- • Put fast feedback in hooks and real enforcement in CI and branch protection, knowing which is which.
- • Keep a large repository fast with partial clone, sparse checkout, worktrees and scheduled maintenance.
- • Prove that the author field is unverified, then establish trust with signing, protection and CODEOWNERS.
- • Run six recovery drills against a deliberately wrecked repository and record the timings.
🛡️ Best Practices in Production
The short version of this path. Every lesson also ends with the specific mistake it exists to prevent.
- ✓ Commit small and often; merge to trunk at least daily so integration problems stay small.
- ✓ Write commit subjects in the imperative under 50 characters, and use the body to explain WHY.
- ✓ Use
git add -pto stage deliberately, so each commit is one reviewable idea. - ✓ Rebase your own unpublished branch; merge the finished branch into main.
- ✓ Force-push only with
--force-with-lease, never plain--force. - ✓ Take a free escape hatch before anything destructive:
git tag backup/$(date +%s). - ✓ Use annotated, signed tags for releases, and stamp
git describeinto your build. - ✓ Enable
rerere,pull.rebaseand a.gitattributeswith* text=autoon day one.
- ✗ Rebasing commits other people have already pulled — their next pull duplicates the entire history.
- ✗
git reset --hardwith uncommitted work in the tree. The reflog cannot recover what was never committed. - ✗ Committing secrets and then deleting the file. The blob stays in history — rotate first, then rewrite.
- ✗ Committing generated output, dependencies or large binaries. Every clone carries them forever.
- ✗ Force-pushing a branch mid-review, which invalidates every comment the reviewer left.
- ✗ Long-lived branches. Conflicts grow superlinearly with divergence.