Git & Tooling — Version Control That Clicks
You delete a file you needed, your teammate’s push overwrites the function you spent an hour on, a “quick fix” breaks main an hour before a demo. Every one of these is a solved problem — git solves it — and yet git is the tool more developers fake their way through than any other. This track makes you the person on the team who actually knows what git is doing, instead of the one googling the same three commands forever.
The Goal
- Stop fearing git by seeing the one picture that explains all of it — the commit graph
- Move through the track in order: mental model first, then branching, remotes, recovery, daily workflow
- Connect the teaching to the real errors you’ll hit — the troubleshooting docs are wired in as the “when it breaks” companion
- Build muscle memory in PowerShell on a throwaway repo, so the real repo is never where you experiment
Why most people fear git
Most people learn git as a list of spells. git add, git commit, git push — type them in this order and it usually works. They never learn what those commands do, so the moment anything goes sideways — a conflict, a detached HEAD, a “your branch has diverged” — they have nothing to reason with. They panic, they paste into AI, sometimes they delete the whole folder and re-clone. You have probably done at least one of these.
Here is the thing nobody tells you up front: git is simple once you can see the graph. Underneath every command is one data structure — a chain of snapshots, each pointing back at the one before it, with movable labels (branches, tags, HEAD) marking positions in that chain. Every git command is just adding a snapshot to the chain or moving a label. That’s it. The fear comes entirely from operating a thing you can’t see. This track’s whole job is to make the graph visible, and once you’ve seen it, the fear does not come back.
That is also why the order matters. You cannot understand branching until you understand what a commit is. You cannot understand pull until you understand fetch and refs. So we build it floor by floor.
Here’s the graph this whole track is about — every command you’ll learn is just adding a node or moving a label on a picture like this:
There’s a second reason git scares people, and it’s worth naming: git is genuinely unforgiving about destructive commands like reset --hard and push --force, so the stakes feel high. But the flip side — which you’ll prove for yourself in module 04 — is that git keeps a 90-day safety net (the reflog) of almost everything you do, so “I lost my work” is nearly always “I can’t find my work yet.” The whole reason this track exists is so that when something goes sideways, you reason instead of panic.
How to use this track
- Go in order. Each module assumes the previous one. Don’t jump to merging before the mental model clicks.
- Keep a terminal open. Every module has hands-on PowerShell on a throwaway repo. Never experiment on a repo with work you care about — that’s what
git-labfolders are for. - Bookmark the troubleshooting docs at the bottom for the day a real error lands.
The modules
| # | Module | What it gives you |
|---|---|---|
| 01 | The Mental Model: Commits, Trees & Refs | The picture everything else rests on — snapshots, parents, refs, the three trees |
| 02 | Branching, Merging & Rebasing | Branches as cheap labels; fast-forward vs 3-way merge; rebase and its golden rule |
| 03 | Remotes, PRs & Collaboration | origin, fetch vs pull, tracking branches, the pull-request workflow with the gh CLI |
| 04 | Undo & Recovery: There Is Almost Always A Way Back | The reflog safety net, reset vs revert, restoring deleted work, stash, amend |
| 05 | Daily Workflow & Tooling | A sane everyday loop, commit messages that earn their place, .gitignore, aliases, hooks |
Start at module 01 and go in order. Each one assumes the one before it. By module 04 you’ll understand why “there’s almost always a way back” is literally true, and that single fact is what turns git from a source of dread into a safety net you lean on.
When it breaks — the troubleshooting companion
The modules teach the model. These two docs are real errors hit on real repos, written up the moment they happened — keep them bookmarked for the day the same thing happens to you:
| Doc | The situation it rescues |
|---|---|
| Needs Merge / Resolve Index First | You started a merge, hit a conflict, never finished it — and now git won’t let you switch branches |
| git fetch Updates Your Knowledge, Not Your Files | ”But GitHub says something different” — why git status can lie and fetch is the safe first move |
Read them now for the mental models, then again the day you trip over the exact error. They map cleanly onto the track: the merge-conflict doc lands on top of module 02 and module 04; the fetch doc is the short version of half of module 03.
Check Yourself
Answer out loud before opening each box. If you can’t, that’s exactly the gap this track fills.
What is the single data structure underneath every git command?
A chain of commits — snapshots, each pointing back at its parent — with movable labels (branches, tags, HEAD) marking positions in that chain. Every command either adds a snapshot or moves a label.
Why do most people fear git, in one sentence?
Because they learn it as a list of spells and operate a thing they can’t see — so the moment anything goes sideways they have nothing to reason with. Making the graph visible is what removes the fear.
What is a branch, mechanically?
A cheap, movable label that points at one commit. Switching branches moves a pointer; it does not copy your files.
Why does this track insist you go module by module in order?
Each module rests on the previous one. You can’t understand branching without knowing what a commit is, and you can’t understand pull without fetch and refs. It’s built floor by floor.
Git is unforgiving about destructive commands — so why isn't "I lost my work" usually true?
Because git keeps a ~90-day safety net (the reflog) of almost everything you do. “I lost my work” is nearly always “I can’t find my work yet” — you prove this to yourself in module 04.
Where do you practice every command in this track, and why never on a real repo?
On a throwaway git-lab repo in PowerShell. The real repo is never where you experiment — you build muscle memory somewhere a mistake costs nothing.
How do the two troubleshooting docs map onto the modules?
The merge-conflict doc (Needs Merge / Resolve Index First) lands on top of module 02 and module 04; the fetch doc is the short version of half of module 03.
Which module should you open first, and why not skip it?
Module 01 — The Mental Model. Typing git commit daily and seeing the graph are two different skills — the second one is what makes git stop scaring you.
Start here
Open Git 01 — The Mental Model. Do not skip it because you already type git commit daily — typing the commands and seeing the graph are two different skills, and the second one is the one that makes git stop scaring you. Have a terminal open; you’ll be running real commands on a throwaway repo within five minutes.
Track starting? Add it to today’s tracker