Project Safe: git

1. You do not need to memorize git commands

— Lyokh, — 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. Open the agent and ask in plain words: “set up a safe for the project.” Just words. Not a command — a request.

Tommy tries. He types human language into the chat: “set up git in the project so we can roll back changes.” And the agent itself, in the terminal, performs exactly what Oliver used to type by hand:

● git init
  Initialized empty Git repository in /portal/.git/

— That’s it, the safe is set up, — Alex says. — The same command granddad typed with a finger. Only he did it from memory, and you do it with words. Notice: git init was typed by the agent, not by you. You said what you wanted; it translated that into a command.

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 already there — Oliver set it while he was showing the commands. Tommy didn’t bother checking it; he trusted granddad.

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

— All right, then, — Alex nudges 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. Green for what the agent added, red for what it removed:

  reward-flow.js
+   const reward = base * multiplier;    // lines the agent added
-   const reward = base;
  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 you 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 commit -m "fix: reward calculation in reward-flow"
  [fix-reward e4f5g6h] fix: reward calculation in reward-flow

— 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 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. It is the same as granddad’s git diff, just handy in the session, 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.

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. The session finished, the laptop slept, the conversation closed. 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.

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.

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