Shipping Software with Git + Claude Code · step 1 of 5 draft

Checkpoint commits

An agent edits at machine speed, which means it also breaks things at machine speed. The commit is your save point: small, frequent, single-purpose. With checkpoints every few minutes of agent work, any mistake costs a git diff and a decision, not an afternoon of digging through history.

You’ve met this before. “Commit early, commit often” is as old as version control. The agent twist is volume and asymmetry: the agent produces changes faster than you review them, so the checkpoint cadence (not the review cadence) is what bounds how much work a bad turn can destroy.

The habit

Try it

TRY IT The wall of diff

you

Good session: the retry logic, the config rename, and the new export flag all work. Commit it.

agent

Three hours of work, three unrelated changes, currently one big pile in the working tree.

Pick the agent's next move, then see where it leads:

you

The retry logic is looping forever in production. Revert it.

agent

The revert takes the config rename and the export flag with it: they're welded into the same commit. I'll have to revert all three, then re-apply two of them by hand from the old diff. Twenty minutes of surgery for what should have been one command.

the baseline

One commit, three purposes: revert stops being surgical, bisect stops being useful, and the 23-file diff was never really reviewable in the first place.

you

The retry logic is looping forever in production. Revert it.

agent

git revert a1b2c3d: done, retry gone, rename and flag untouched. And for next time: the redo branch starts from a clean history where the retry change is one readable diff.

correct

Three purposes, three commits: the bad one reverts in one command, the good ones stand, and each diff was small enough to actually read at review time.

agent

Done: 23 commits. Caveat I should flag: the retry change spans 6 of them, so commits 4 through 9 each leave the build broken until the next lands.

you

So bisect lands on a broken-by-construction commit, and reverting the retry means finding six needles.

plausible but wrong

Granularity by file, not by purpose: every commit is small and none is coherent. The unit of a commit is the change that stands together: builds green, reverts whole.

Do it by hand

Next session, open with: “after each change that builds and passes tests, propose a commit: show me the diff summary and a one-line why.” You approve each one; after a day it’s habit.

Or paste this into Claude

For the rest of this session: after each coherent change that builds
and passes tests, stage exactly the files that change belongs to and
propose a commit: show me the short diff stat and a message whose
first line says what and whose body says why. Never batch unrelated
changes into one commit; if you notice unrelated edits you made along
the way, list them separately and ask. If more than ~30 minutes of
work has gone uncommitted, say so and propose a checkpoint. Then add
this as a "checkpoint commits" line to CLAUDE.md so it sticks. Show
me the diff first.

Watch out