Episode 154 · The version that worked at 16:30

Git as your safety net: save points, branches and the right undo

Thursday, 18:00. The new support search worked at 16:30; Maya even showed it to the support lead. Now the page is blank, 34 files are changed, and the last commit is from Monday. Twice, the agent was asked to "undo your last changes".

Save often, try things on a side branch, and know which undo to use. Then no agent session can cost you more than a few minutes.

30 min intermediateCommits as save points for agent workUndo in git: restore, revert, resetOne branch per agent taskGit commits & branchesRollback vs roll-forward

Problem
A four-hour agent session worked at 16:30 and is broken at 18:00. 34 files changed, nothing committed since Monday. The working version exists nowhere in git.
Why the simple system fails
Treating the agent's session (or the editor's undo) as the history. Asking the agent to "undo the last changes" makes it guess what the last changes were, and usually makes things worse.
Engineering concept
Commits are save points you choose. Commit every time the work reaches a known-good state, on a branch dedicated to the task, so any experiment can be thrown away in one command and any bad merge undone safely.
Technology
git status, diff, switch -c, add, commit, restore, stash, reset --hard (local only), revert (shared branches), pull requests, branch protection, .gitignore, and agent permission rules for git.
Trade-offs
Frequent commits make history noisy; rare commits make work fragile. Commit often on a task branch, squash or tidy at merge. Reset is clean but rewrites history; revert is safe on shared branches but adds commits.

The problem

2 min

Thursday, 18:00. A session on the support tool's search since 14:00, on local main. At 16:30 it worked. Then: "add autocomplete".

Maya · Product manager
The search page is blank. I asked it to "undo your last changes" twice. Now there are different errors.
You · Engineer at StayHub
git status: 34 files modified. git log: last commit Monday.
Lina · Senior engineer, your mentor
You lead this one. Guess first.

The big idea

4 min

Nothing to go back to

The big idea

Commit at every green step, and undo with exact git commands, never with the agent's memory.

Git wasn't the problem; it was never asked to remember anything. A commit at 16:30 would have made the fix one command. Instead, the 16:30 version was rebuilt from the plan the next morning: about two hours, repeated.

How it works

5 min

In a long game you save before the boss fight, and if it goes badly you reload; you don't replay your moves backwards from memory. Git saves only when you commit.

The safety net, piece by piece

1
Working tree is not history
The is the files on disk right now. Editing overwrites them; nothing here can be brought back.
2
Commits are save points
A is a snapshot of the whole project with a message. Commit when a step passes its tests, after a look at git status and git diff: no .env files, no stray exports.
3
One branch per task
A is a separate line of work. Start clean, from an up-to-date main; experiments never touch main.
4
Undo unsaved edits
git restore throws them away; git stash sets them aside in case part is useful.
5
Reset vs revert
Reset moves your own branch back to a commit, dropping later ones. Revert adds a commit that undoes another: the only safe undo on a shared branch like main or release.
6
What git can't undo
Git restores code, not emails sent, payments taken or deleted data. Those need plans that flag side effects, additive data changes and backups.

Watch a decision being made

4 min

Worked example

You replay the afternoon with a safety net

Redo the support-search work so the 17:30 failure costs minutes, not a morning.

1Start clean, on a branch
"Show git status; it must be clean. Switch to main, pull, create support-search-filters."
Why: Leftovers would end up in your commits; the branch keeps experiments off main.
2Commit each green step, after a look
15:10 API filters, 15:55 date range, 16:30 UI. Before 15:55, git status shows a new .env.local with a test API key: "Don't commit it; add it to .gitignore."
Why: Each commit is a known-good point; looking first keeps secrets out of history.
3Go back exactly, with proof
17:30: autocomplete broke 14 files, uncommitted by design. "Stash them as 'autocomplete attempt', show git log -3, run pnpm test." HEAD is 16:30; tests green.
bash
```
git stash push -m "autocomplete attempt"
git log --oneline -3
pnpm test
```
Why: Stash keeps the attempt; the log and test run prove you're back.
4Share through review
Push the branch, open a PR. If a bad merge reaches main, git revert through a PR, never reset or force push.
Why: Shared history must not be rewritten.

In real life

3 min

Two well-known ways to keep history

Automatic version history (e.g. Google Docs)

Every change saved automatically
Browse back by time
Nobody marks "this worked"

Nothing lost; good points unmarked.

Explicit commits (git)

Saved only when you commit
Each save has a message
Shared and reviewed by the team

You mark the known-good points.

What goes wrong

3 min

Long sessions with no commits

The working version is overwritten; nothing to go back to.

Instead

Commit at every green step on a task branch.

"Undo your last changes"

The agent rebuilds from memory; you get a third version.

Instead

Exact git operations to a named commit, plus a test run as proof.

Force push or reset on a shared branch

Others' commits disappear from it.

Instead

Revert or merge; protect main and release; pushes stay behind a human.

Trade-offs

3 min

Commit rule	Fits when	You pay
One commit per feature	Tiny, one-step changes	No save points; one bad step loses hours
Green-step commits, squash at merge	The default for agent tasks	The habit; step history only on the branch
Auto-commit every edit	Rarely; stash keeps experiments better	Broken states everywhere; good point hard to find

Friday, 10:00. The team sets its git rules for agent work.

Maya · Product manager
Make the agent commit after every edit. I never want to lose work again.
Karim · CTO
Then main has 400 commits saying "edit file". One clean commit per feature.
Maya · Product manager
One commit per feature is how we lost Thursday afternoon.

Your job as tech lead

4 min

Claude Code can write the code for this. You still own the decisions, and you have to know what good looks like to accept or reject its work.

Decisions you own

When a step counts as green and gets committed: tests pass and you've looked at the result.
Which git commands the agent runs alone (status, diff, log, commit on its branch) and which need you (push, reset, rebase, force push, merges to main or release).
Which branches are protected so nobody, human or agent, can force push them.

Tell Claude Code

Start safely: run git status (it should be clean), switch to main, pull, and create support-search-filters. Follow the approved plan one step at a time. After each step, run pnpm test; if it passes, show git status and git diff --stat, then commit with a message saying what and why. Never commit .env files. If a step breaks things, stash the changes, show git log -3 and run the tests. Don't push.

Check before you accept

Clean status at the start, and you're on a task branch, not main.
git log shows a commit after each green step, with messages you understand.
After any undo: git log and a test run as proof.

Red flags

Hours of agent work and no commits since the morning.
push --force, reset --hard or rebase proposed on main or release.
"I've reverted my changes" with no git command shown.

Check yourself

2 min

Q1/3Scenario

The search worked at 16:30. You never committed. At 18:00, after more agent edits, it's broken. What can git give you back?

How confident are you?

Next: you can now undo any bad change. But how do you know a change is bad before guests find out, when 24 tests are all green?

Finished?

Mark it complete to update your skill map.

Next: Testing without coding: make the agent prove it

Go deeper (optional)You don't need this to understand the lesson. Open it when a project needs the details: Technical deep dive, Visual diagram, Analogy, Why it matters, Check your understanding, Practice ladder, Explain it yourself.

Technical deep dive

Back to 16:30 in one command

Worked example

Replay the afternoon with a safety net

Redo the support-search work so that the 17:30 failure costs minutes: branch, save points, a look before each save, and an exact undo.

1Start clean, on a branch
Ask the agent: "Show git status; it must be clean. Switch to main, pull, and create the branch support-search-filters."
bash
```
git status
git switch main && git pull
git switch -c support-search-filters
```
Why: Unrelated leftovers would end up in your commits. The branch keeps every experiment away from main.
2Commit each green step
After each plan step passes its tests: commit with a clear message. 15:10 API filters, 15:55 date range, 16:30 UI.
Why: Each commit is a known-good point you can return to exactly.
3Look before saving
Before the 15:55 commit, git status shows a new .env.local holding a test API key. Ask: "Don't commit .env.local; add it to .gitignore."
Why: Commits are forever-ish and shared. Looking first keeps secrets and stray files out of history.
4Experiment on top
17:00: "Add autocomplete." By 17:30, 14 files changed, tests red. Nothing committed, by design.
Why: Failed experiments stay uncommitted, so throwing them away loses nothing good.
5Go back exactly, with proof
"Stash the uncommitted changes as 'autocomplete attempt', show git log -3 and run pnpm test." HEAD is the 16:30 commit; tests green.
bash
```
git stash push -m "autocomplete attempt"
git log --oneline -3
pnpm test
```
Why: Stash keeps the attempt in case part of it is useful. The log and the test run are the evidence you're back.
6Share through review
Push the branch and open a PR. On main, a bad merge would be undone with git revert, through a PR, never reset or force push.
Why: Shared history must not be rewritten. Revert keeps everyone's commits and leaves an honest record.

Situation	Ask the agent for	Throws away
Uncommitted edits are bad	git restore (or git stash to keep them)	Those edits (nothing, with stash)
Last commits on your own branch are bad	git reset --hard <good commit>	Those commits
A commit on main or release is bad	git revert <commit>, via a PR	Nothing: adds an undo commit

Choose by what you're willing to lose and who shares the branch.

Visual diagram

main (shared)

Save 1: search API

Save 2: new filters

Experiment (uncommitted)

Pull request

Revert (if needed)

Click a component

A task branch with save points. Green commits are known-good states; the failed experiment is thrown away with one command.

Analogy

A long video gameGit with an agent

A long video gameSaving before the bossGit with an agentCommitting at a green step
A long video gameThe game in progressGit with an agentThe working tree (unsaved)
A long video gameA separate save slotGit with an agentA branch for the task
A long video gameReload the last saveGit with an agentRestore or reset
A long video gameNew move cancels a bad oneGit with an agentRevert on a shared branch

Where the analogy breaks: games autosave all the time. Git only saves when you commit. That's why committing at every good moment is the habit to build.

Why it matters

A session goes wrong at 18:00

No saves since Monday

The 16:30 version is gone
"Undo it" makes a third version
Hours of work lost

A bad afternoon.

Saved at every green step

Last good save: 16:30
One command to go back
Attempt kept aside, just in case

Ten minutes lost.

And remember the limit: git brings back code. It can't unsend an email, refund a charge or restore deleted data. Those need other safety nets.

Check your understanding

Q1/3Decision

Match each situation to the right undo:

Uncommitted edits to 3 files are wrong

Your last 2 commits on your own task branch are wrong

A merged commit on main broke checkout

You want to set an experiment aside, not lose it

How confident are you?

Practice ladder

Step 1 · Trace

Predict what each command does

Scenario Warm-up

On your task branch:

$ git log --oneline -3
c3 Support search UI            (16:30, worked)
c2 Search: date range filter
c1 Search API: filters
$ git status
modified: 14 files (autocomplete attempt, tests red)

For each command, say what the files look like afterwards and what is lost: (a) git stash, (b) git restore ., (c) git reset --hard c2, (d) git revert c3.

Step 2 · Complete

Finish the git rules in CLAUDE.md

Hands-on Practice

Lina started the git section of CLAUDE.md. Fill in the three gaps.

## Git
- Before starting, run git status; it must be clean.
- Work on a new branch per task, created from an up-to-date main.
- Commit ___                                          (1)
- Before each commit, ___                             (2)
- Never ___                                           (3)
- To undo, use exact git commands to a named commit and run the tests after.

Step 3 · Solve

Two problems, two undos

Scenario Practice

Monday morning:

On your branch voucher-limits (pushed, only you use it), the last 2 commits from Friday evening made the voucher form unusable. The commit before them was fine.
Last week's merged commit a71c0de on main changed the support search ranking, and support says results are worse.

Write the exact instructions you'd give the agent for each, including the evidence you want.

Step 4 · Decide

What git may the agent do alone?

Decision Stretch

Write the team's git permission rule for Claude Code: which git commands it may run without asking, and which always need a human. Use the form "We chose X over Y because…, accepting the risk of…".

Explain it yourself

Explain to Maya how to work with Claude Code so that a session going wrong never costs more than a few minutes.

0 words