Project Safe: git

1. You do not need to memorize git commands

“Alex.” Tommy waves a notebook. “Granddad dictated eight commands to me here, with flags. Says I should know them by heart. I will never remember this in my life — git reset --hard, git checkout -b, which flag goes where… My head hurts just looking at it.”

“Then let’s see who is supposed to type them at all.” Alex snorts, almost cheerful for the first time all day. “Granddad was right about the model — he gave you gold there. But the ‘by heart’ part was from his youth; back then it had to be that way. You do not need to cram. Granddad has already set up the safe for you — so take a look inside. Open the agent and ask in plain words: ‘show me which checkpoints are in the project.’ Just words. Not a command — a request.”

Tommy tries. He types human language into the chat: “show me which restore points are already in the project.” And the agent itself, in the terminal, performs exactly what Oliver used to type by hand:

● git log --oneline
  a1b2c3d working portal before changes

“There it is, granddad’s checkpoint,” Alex says. “The same command granddad typed with a finger. Only he did it from memory, and you do it with words. Notice: git log was typed by the agent, not by you. You said what you wanted; it translated that into a command. And in a new project you set up the safe the same way: ‘set up git in the project’ — and the agent types git init itself.”

Tommy glances at the line in the terminal:

“So the whole granddad notebook… I don’t have to learn it?”

“You don’t.” Alex shakes his head. “The AI agent carries out all these commands through the terminal. There are no separate ‘git buttons’ in Claude Code: git is just another tool for it, like everything else it handles in your terminal. You need to know the model — main, branch, checkpoint, rollback — and you can ask it to turn that into commands with words. Granddad’s syntax with flags is his problem, not yours.”

Tommy visibly exhales. The scariest part — having to cram a notebook full of flags — has fallen away.

“But keep granddad’s model in your head,” Alex adds. “The request-by-words approach works only if you understand WHAT you are asking for. If you say it vaguely, the agent will type it vaguely too. Granddad gave you understanding; I’m giving you convenience. Together — that’s strength.”

The safe is set up, and the first checkpoint (working portal before changes) is in place — Oliver set it while he was showing the commands, and now Tommy has seen it with his own eyes. Granddad cleaned up his practice branch after himself: on main there is one clean checkpoint.

2. Battle run: branch → fix → rollback, main intact

“All right, then,” Alex says, nudging him, “let’s protect your reward-flow change the grown-up way, step by step. Everything you wrote in the brief is about to become real actions. And notice the difference from granddad: he typed commands himself, while you speak in words and the agent executes the command under the hood.”

Step 1. Isolate the work in a branch — so main stays untouched. Tommy tells the agent in words:

Before the task, create a fix-reward branch and work in it; do not touch main.

The agent translates the request into a command and runs it:

● git checkout -b fix-reward
  Switched to a new branch 'fix-reward'

“There you go,” Alex comments. “The terminal wrote exactly that: ‘switched to a new branch fix-reward.’ Now the agent is working inside it. Whatever it messes up in there — your working main stands off to the side and does not even know about it.”

Step 2. Make the change — and inspect what the agent changed BEFORE accepting/committing. The agent made edits in reward-flow. But before saying “accepted,” Tommy opens the changes view:

/diff

On the screen is a line-by-line picture of the change. Red for what the agent removed, green for what it added in its place:

reward-flow.js
-   const reward = base;                 // the line the agent removed
+   const reward = base * multiplier;    // the line it added instead
  leaderboard.js
+   sortByScore(players);                // ← and this was not supposed to be touched

Tommy stares at it — and frowns.

“Listen, why did it touch that… it did not just change the calculation. This thing in leaderboard.js — where did that come from? I did not say a word about the leaderboard.”

“Exactly why you look.” Alex nods. “The approach is off: the agent reached into a neighboring area. Good thing you checked BEFORE, instead of accepting blindly. By the way, you can also see these same changes directly in the open file in the editor — where the agent made edits, the lines are highlighted the same way. The diff and the file show the same thing; look wherever it is more convenient.”

Step 3. Roll the branch back to a clean checkpoint — the crooked changes disappear. Tommy does not go in and manually clean up leaderboard.js. Since the approach is crooked, he asks to reset the branch entirely:

Reset the branch to the last saved checkpoint; let’s start over.

The agent translates that into a rollback command:

● git reset --hard HEAD
  HEAD is now at a1b2c3d working portal before changes

The terminal confirmed it: the branch returned to the very checkpoint Oliver saved at the beginning. The entire bad pass — both the correct calculation and the extra tail in the leaderboard — was wiped in one shot, as if it had never happened.

Step 4. Clean pass — and save the new checkpoint. Now Tommy gives the change again, with a tighter spec (“touch only the calculation, do not touch anything adjacent”). This time /diff shows only reward-flow.js, nothing extra. Tommy accepts it and asks to save the checkpoint:

Save the change: reward calculation in reward-flow.

● git add src/reward-flow.js
● git commit -m "fix: reward accrual in reward-flow"
  [fix-reward e4f5a6b] fix: reward accrual in reward-flow
   1 file changed, 1 insertion(+), 1 deletion(-)

The same two moves granddad made — add and commit — only this time the agent typed them.

“And notice the key thing,” Alex sums it up. “All this time your main stayed untouched. You broke things in a branch, rolled the branch back, redid it, saved the checkpoint — and the working portal was never harmed. That’s ‘break it → roll it back → as if nothing happened.’ Only now it is not just talk, it is at the repository level. Deeper. More reliable.”

3. The same commands in plain words

“Wait.” Tommy scrolls back through the terminal. “I see that during the whole run I did not type a single command from the notebook myself. I spoke in words, and Oliver’s checkout and reset appeared on their own.”

“That is the main skill in working with AI,” Alex says, suddenly energized. “Not commands. How to ask. In granddad’s notebook, the left column lives in your head: main, branch, checkpoint, rollback. The right column, the syntax with flags, is now held by the agent. Let me rewrite granddad’s notebook into human language — so you can keep it close at hand.”

He counts on his fingers — each action is the same command Oliver used to type by hand, only now it is just a request in words:

• Set up the safe (once per project): “set up git in the project” → the agent runs git init.
• Save a restore point: “save the current state” or “save a checkpoint, everything works here” → the agent runs git add and git commit.
• Move the work aside: “create a branch for this change, do not touch main” → the agent runs git checkout -b.
• See what changed before accepting: this one is even simpler — Claude Code has its own command, /diff, and you type it yourself. Under the hood it is the same git diff granddad used: it shows everything that has changed since the last checkpoint, only it is right at hand in the session and interactive.
• Roll back a bad run entirely: “reset the branch to the last saved checkpoint” → the agent runs git reset --hard.

“Notice the pattern,” Alex says. “On the left is what you want, in model terms. On the right is the command you are not required to know by heart. Your half is the left one. You formulate the intent, and the translation into syntax is the agent’s job. The more precisely you say what you want, the less it will muddle it.”

“So if I say it vaguely, it will do it vaguely too.” Tommy catches on.

“Exactly. ‘Listen, just do something sensible with the branches’ — bad request, the agent has to guess. ‘Create a fix-reward branch and work only in it’ — good request, nothing to guess there. It is the same skill you trained with specs: say it clearly, get a clear result.”

Request in words → agent’s command. Your half is what you want and how to ask; the agent’s half is the command. Set up the safe: “set up git in the project” — the agent usually types git init. Set a point: “save the current state” — git add and git commit. Branch off: “create a branch for this change, do not touch main” — git checkout -b. Review the edit: you type /diff yourself — no agent needed, you look, before accepting. Roll back: “reset the branch to the last saved checkpoint” — git reset --hard HEAD. History: “show me which checkpoints are in the project” — git log --oneline. Which command the agent actually chose shows up in the confirmation request; read it before you allow it. Vague — the agent guesses: “just do something sensible with the branches”. Clear — nothing to guess: “create the branch fix-reward, work only in it”. You hold the model and phrase the request — the agent types the syntax. Request in words → agent’s command Your half The agent’s half What you want How to ask in words The agent usually types “set up git in the project” git init Set up the safe “save the current state” git add + git commit Set a point “create a branch for this change, do not touch main” git checkout -b Branch off you type it yourself: /diff no agent needed — you look, before accepting Review the edit “reset the branch to the last saved checkpoint” git reset --hard HEAD Roll back “show me which checkpoints are in the project” git log --oneline History Which command the agent actually chose shows up in the confirmation request. Read it before you allow it. Vague — the agent guesses “just do something sensible with the branches” Clear — nothing to guess “create the branch fix-reward, work only in it” You hold the model and phrase the request — the agent types the syntax

4. Why diff, if main is protected anyway

“And this diff.” Tommy does not let it go. “I’m in a branch now, main is protected. Maybe I do not need to look? If it messes up, I’ll roll it back, no big deal.”

“You can do that too.” Alex does not argue right away. “But look at the difference. A rollback happens only after you have already messed up. A diff is before you accept. It is your first barrier between ‘the agent proposed it’ and ‘it landed in the project.’ The habit is simple: before you say ‘okay, I accept,’ check exactly what it changed. What it added, what it removed.”

He presses the point a little harder:

“What did you trip over just now in the battle run? The agent touched something extra. If you had accepted blindly, that extra would have gone into the branch and then maybe into main too. But you checked the diff — and caught it. Rollback saves you from what has already been recorded. Diff catches it before recording. Those are different moments.”

“So it trains me not to nod ‘go ahead’ without looking.”

“Exactly. And looking is not ‘glance over it for the sake of it.’” Alex comes back to that diff. “The diff shows you exactly two things: what the agent added and what it removed. Green and red, line by line. Your job at this stage is not to judge whether the code is good (that is Sam’s problem), but only to verify: is everything it touched part of your task? You asked to fix the calculation. Then the diff should contain only the calculation. If something else appears, from another file, from another area, then there is your warning sign.”

“Like with that leaderboard.” Tommy nods. “I did not ask for it, but it popped up in the diff.”

“Exactly. You were not checking whether the agent sorted the leaderboard correctly. You simply saw: that was not in the task — and you were already on alert. That is the entire skill for today. Not ‘evaluate the quality of every line,’ but ‘compare the list of changes with the list of what you asked for.’ One short comparison before every acceptance.”

He emphasizes it:

“For now — only this: look at what changes and catch the foreign stuff. A deeper review — ‘this is extra, this is dangerous, this was quietly rewritten by the agent’ — will come later, separately. Right now the basic reflex is simple: do not accept code without checking whether it belongs to your task.”

5. Why /rewind did not save you that night

Tommy leans back and finally asks the question that had been bothering him since morning:

“Listen, then why did that night fall apart? I had /rewind. I hit it — and it did not save me. Now I have git. So what is the difference between them? They are both ‘rollback,’ aren’t they?”

“Good question, about time.” Alex counts it off on his fingers. “Now you have three different safety nets, and they do not duplicate each other. They work at different moments and on different floors. Do not mix them up.”

“The first is diff. It catches a mistake before the code enters the project. The entry barrier.”

“The second is /rewind. It rolls back within the session, right in the live conversation. While you are here, chatting with the agent, it rewinds the current run’s changes.”

“The third is git. It brings back what has already been written to disk. Branch, commit — the deepest floor. It works even when the conversation is over and the agent remembers nothing at all.”

He stops at the core point:

“And now look at what happened that night. Something crashed in the night, and the session was wiped out — along with its checkpoints. And the changes had long since been written to disk. And you hit /rewind — the safety net that lives in the session. But the session was already gone, nothing was left to rewind. The button did not reach the disk not because it was bad. It was simply on a different floor. It was never meant to drag the whole repository back — that is what git is for, the lower floor. And that night, git had not been built yet.”

Tommy is silent. The lifebuoy with a hole from the third level settles into place completely. The hole is not a defect in the ring. It is that the ring cannot do the job of an anchor. Different things, different floors.

“So I need all three,” he says slowly. “Not one. Diff at the entrance, rewind in the conversation, git on disk.”

“All three. Each on its own floor. That night you only had the middle one, and you fell through to the bottom, where there was nothing.”

Three safeguards: one filter and two nets. Before accepting — /diff, the filter: you see what the agent changed, before accepting; check: is everything touched part of your task? It brings nothing back — it catches before writing. After accepting, upper floor — the session with the agent: /rewind, a net, undoes the agent’s edits while the session is intact; files changed only through the terminal can be restored only by git. After a session crash: the session was wiped, the checkpoints are gone, /rewind is there, but there is nothing to rewind. Lower floor — the project folder on disk: git, the net on disk, the branch and checkpoints you set; it brings back what was written — even when the session is gone and the agent remembers nothing. That night, on autopilot: /diff — not checked, everything allowed in advance; /rewind — was there, but the session got wiped; git — not built, nowhere to fall. Diff — at the entrance, /rewind — in the conversation, git — on disk. You need all three. Three safeguards: one filter and two nets Before accepting After accepting After a session crash Upper floor session with the agent Lower floor project folder on disk /diff — filter you see what the agent changed — before accepting check: is everything touched part of your task? brings nothing back — catches before writing /rewind — net undoes the agent’s edits while the session is intact files changed only through the terminal — only git restores A crash wiped the session checkpoints wiped out /rewind is there, but nothing to rewind git — net on disk the branch and checkpoints you set: brings back what was written — even when the session is gone and the agent remembers nothing That night autopilot /diff — not checked: allowed everything in advance /rewind — was there, but the session got wiped git — not built: nowhere to fall Diff — at the entrance, /rewind — in the conversation, git — on disk. You need all three

6. A candid note so there are no surprises

“And one honest little thing at the end.” Alex does not let him drift into a fairy tale. “About rollback safety. git reset --hard is a command with character: it wipes uncommitted changes without asking. And know this right away: there is no magic ‘git fuse’ in Claude Code that will catch your hand on that one — do not count on it. What protects you is something else, something you already know: the usual confirmation prompt before the agent acts. Before it runs something destructive in the terminal, the agent normally asks for permission — exactly the same way it does for file edits. That extra confirmation is your safety net: if you see git reset --hard in the confirmation request, pause for a second and think whether you really want to reset something you do not mind losing. There is no separate git nanny on top; there is you and your ‘allow.’”

“And one last thing. Command names and the exact look of the screen may change a little over time. Granddad crammed them twenty years ago — and half of them have been written a little differently since then. So it is more important for you to keep the model — isolation in a branch, a restore point, rollback — rather than specific buttons. The model will not go stale, and the agent can plug in the syntax fresh.”

Tommy sums it up himself:

“In short. The safe is git. A branch so the agent works away from the working copy. Diff so you can check before accepting. Commit is a real checkpoint on disk. Rollback is bringing the branch back to the checkpoint, as if nothing happened. And the agent does all of it; I only speak in words. Three nets on three floors, and I need all of them.”

“This run was a practice one, with me backing you up,” Alex says. “Clean up after it, like granddad: go back to main and wipe out the practice branch. You will do the real run on your own.”

Tommy writes it in words: “go back to main and delete the fix-reward branch.” The agent asks for permission — deleting a branch erases its checkpoint — and Tommy pauses for a second, as he was taught, and allows it:

● git checkout main
  Switched to branch 'main'
● git branch -D fix-reward
  Deleted branch fix-reward (was e4f5a6b).

Battle run: what happens in git. On main — the checkpoint “working portal before changes”. 1. Branch: you say “create a fix-reward branch, do not touch main”, the agent types git checkout -b fix-reward; the branch starts from this checkpoint, it has no checkpoints of its own yet, main stays aside. 2. Edit: the agent edits files and sets no checkpoint, you look at /diff; the edits sit in the files — there is no checkpoint under them. 3. Rollback: “reset the branch to the last checkpoint” — git reset --hard HEAD; everything unsaved is wiped: both the extra and the calculation; the files are as in the checkpoint “working portal before changes”. 4. Checkpoint: “save the change: reward calculation…” — git add and git commit; the branch gets its first own checkpoint “fix: reward accrual in reward-flow”, main is untouched. 5. Cleanup: “go back to main and delete the branch” — git checkout main and git branch -D; the practice branch is gone along with its checkpoint, main is as it was. An edit isn’t a checkpoint yet. A checkpoint is what you saved; main stays intact throughout the run. Battle run: what happens in git You said → the agent typed What changed in git 1 Branch You: “create a fix-reward branch, do not touch main” Agent: git checkout -b fix-reward main working portal before changes main stays aside fix-reward no checkpoints of its own yet 2 Edit You: give the edit and look at /diff Agent: edits files, sets no checkpoint main working portal before changes fix-reward the edits sit in the files — no checkpoint under them 3 Rollback You: “reset the branch to the last checkpoint” Agent: git reset --hard HEAD main working portal before changes fix-reward everything unsaved is wiped: both the extra and the calculation 4 Checkpoint You: “save the change: reward calculation…” Agent: git add + git commit main working portal before changes main untouched fix-reward fix: reward accrual in reward-flow 5 Cleanup You: “go back to main and delete the branch” Agent: git checkout main + git branch -D main working portal before changes main — as it was fix-reward practice branch gone with its checkpoint An edit isn’t a checkpoint. A checkpoint is what you saved; main intact throughout

“There you go,” Alex concludes, “now we can let the agent into reward-flow for real. The safe is built.”