Branches per milestone, clean commits, and reviewing every AI diff like a pull request.
Module 4 · Git as your safety net for fast, confident AI code.
Beginner Version Control Includes Lab ~45 minmain always working with a branch per milestonerestore, revert, and safe recovery.gitignore, branch for M1, build the first slice, review the diff, and mergePrerequisites: Module 3 — the snippet-vault repo with a committed SPEC.md.
An assistant can rewrite twenty files in ten seconds, sounding completely sure of itself. That speed is exactly why you need a safety net underneath it. Git gives you three superpowers that turn fast-and-risky into fast-and-safe:
| Superpower | What it means |
|---|---|
| A checkpoint | Every commit is a save point you can return to. A bad AI edit is never permanent. |
| A magnifying glass | git diff shows exactly what changed, line by line — so you review before you trust. |
| A time machine | Something broke? git log and revert pinpoint and undo the change that did it. |
You've been committing since your first vibe. This module turns that into a discipline: small commits, branches, and diff review — the habits that make AI-speed development sustainable.
Ninety percent of daily Git is five commands, in a rhythm you'll repeat all day:
| Command | Does |
|---|---|
git status | What's changed and what's staged. |
git diff | The exact line-by-line changes — read this before committing. |
git add <file> | Stage the changes you've reviewed and want to keep. |
git commit -m "…" | Save a checkpoint with a message. |
git log --oneline | The history of checkpoints. |
A good message says why, not just what. Short imperative subject, optional body for context:
Generated and secret files should never enter Git. A .gitignore keeps node_modules/, build output (dist/), and especially .env secrets out of your history. Committing a secret once means it's in the history forever — prevention beats cleanup.
Your main branch should always work. So you never build directly on it — you branch off for each milestone from SPEC.md, do the work there, then merge back when it's done and reviewed.
If the assistant takes a milestone in a bad direction, you just delete the branch — main is untouched. Branches make experiments cheap and mistakes disposable, which is exactly the freedom vibe coding needs.
Treat the assistant as a teammate opening a pull request: you are the reviewer. Before you stage anything, run git diff and read every hunk against this checklist:
| Ask | Why |
|---|---|
| Does it match the spec? | Only the story you're building — nothing extra. |
| Any secrets or keys? | Never let credentials into a commit. |
| Any unrelated changes? | AI often "helpfully" edits files you didn't mean to touch. |
| Do I understand every line? | If you can't explain it, you can't maintain it — ask the assistant to explain, or simplify. |
| Is it small enough to review? | If the diff is huge, split the task and try again. |
Running the app proves it does something, not that it does the right thing safely. The diff review is where you catch the security hole, the hard-coded value, and the sneaky scope creep — before they're in your history.
Because you commit often, recovery is easy. The three you'll actually use:
| Situation | Command |
|---|---|
| Discard un-committed changes to a file | git restore <file> |
| Undo a bad commit, keeping history honest | git revert <hash> |
| Abandon a whole experimental branch | git checkout main then git branch -D <branch> |
Knowing you can undo anything is what lets you move fast with an AI. You can accept a bold change, test it, and roll it back in one command if it's wrong. No fear, no lost work.
You'll set up a proper Git workflow and use it to build the first thin slice of milestone M1 from your spec — reviewing the AI's diff like a pull request before it lands.
Your snippet-vault repo from Module 3 (scaffold, context file, and SPEC.md), and your assistant.
Ask the assistant to generate a .gitignore for a Node monorepo (ignore node_modules/, dist/, .env). Review it, then commit on main:
Point the assistant at your spec and keep the scope tiny:
Before staging anything, read it against the checklist:
Matches the spec? No secrets? No unrelated files? Understand every line? Push back on anything that fails — ask the assistant to fix or explain before you accept.
In REFLECTION.md: paste your git log --oneline, and note one thing you caught while reading the diff that simply running the app would have hidden. Commit it.
Your snippet-vault repo. Self-check before submitting:
.gitignore is committed (no node_modules/ in the repo)feature/ branch and merged into mainREFLECTION.md notes something the diff review caught| Term | Plain meaning |
|---|---|
| Commit | A saved checkpoint of your project at a point in time. |
| Branch | A separate line of work that doesn't affect main until merged. |
| Diff | The exact lines added and removed by a change. |
| Pull request (PR) | A proposed change others review before it merges — here, you review the AI's. |
| .gitignore | A list of files Git should never track (secrets, build output). |
| Revert | A new commit that undoes an earlier one, keeping history intact. |
A clean Git workflow — .gitignore, a branch per milestone, small honest commits, and diff-review-as-PR — plus the first slice of M1 (create + list) built, reviewed, and merged to a working main.
Next up: Module 5 — Vibe-Coding the App. With the workflow in place, we run the real build loop — turning the rest of your milestones into working features, iterating fast, and knowing exactly when to take the wheel from the assistant.