Claude Code can change forty files in ninety seconds. Command+Z in your editor undoes changes in one file, in one window, until you close it.

That gap is the whole reason version control exists, and it matters more for you than for a developer typing every line by hand. You are approving work you did not write, at a speed you cannot proofread.

The idea

Git takes a snapshot of your entire project whenever you ask, attaches a message and a timestamp, and keeps every snapshot forever. A snapshot is a , and the folder holding your project plus all of its snapshots is a . Going back to any snapshot takes one command and about a second.

text
  main    A ----- B ----- C ----- D        <- your history, oldest to newest
                          |        \
                          |         \  "add checkout page"   (you are here)
                          |          \
                          |           HEAD
                          |
                          \-- E ----- F    <- branch: risky-refactor
                                             same history up to C, then separate

  Working tree  ->  git add  ->  Staging  ->  git commit  ->  History
  (your files)                   (chosen                       (permanent)
                                  changes)

How it works

  • The working tree is your files as they are right now. Git watches them but does not record anything until you tell it to.
  • Staging is the holding area you put changes into before saving them. git add -A stages everything that changed. The step exists so you can save two unrelated fixes as two commits, and you can ignore it early on.
  • A commit writes the staged changes into history with your message. git commit -m "add waitlist form". The message is for the you of next month, so write what changed, not "update".
  • A lets you try something without touching the version that works. git checkout -b risky-refactor creates one and moves you onto it.
  • git status is the command you run constantly. It tells you which files changed, which are staged, and which branch you are on.

What to do

  1. Put the project under git before the first AI-written line, not after. In the project root: git init, then git add -A, then git commit -m "starting point".
  2. Commit before you hand over a task, every time. A clean git status at the start of a session means one command puts everything back if the session goes badly.
  3. Undo with the smallest tool that works. git restore src/app/page.tsx throws away changes to one file. git restore . throws away all uncommitted changes and cannot be undone, so run git status first and be sure you want everything gone.
  4. For anything you expect to go wrong, work on a branch: git checkout -b try-new-auth. If it fails, git checkout main and the experiment is simply somewhere else.

Where it breaks

Git only protects what you committed. Uncommitted work is not in history, so an assistant that rewrites a file you never saved a snapshot of has destroyed the previous version, and no git command brings it back. The habit is worth more than git.

It also records everything you stage, including things that should never be recorded. An API key committed once stays in history even after you delete the line, which is why .gitignore exists and why .env.local belongs in it. Chapter 7 covers what to do when a key has already gone in.

Finally, a repository on your laptop is one copy on one disk. That history becomes a backup only once it also lives somewhere else, which is what GitHub is for.