Go back an hour

What it is and why it matters

It happens to everyone. You ask Claude for one change, it makes ten, and an hour later the app won't start. You don't know what it touched and you don't remember how it was before.

Git is the project's history. Every time you save with a commit, you take a snapshot of all the files at that moment. If something breaks, you go back to an earlier snapshot. But you can only go back to a snapshot that exists: if you didn't save, there's no before to go back to.

You don't have to learn the Git commands. Claude writes them. All you need are three sentences, exactly as they are, at the three right moments: before you start, when something breaks, before something big.

The only requirement is that the project uses Git. If it doesn't yet, ask Claude to set it up: it's one line.

1. Before you start: save

Before I give Claude a job, I write this:

Before you touch anything, save the current state of the project with a commit, so we can come back here.

Claude makes a commit: it saves the current state with a message that says what's in it. That commit becomes the safe point. Whatever happens next, you can go back there.

I also do it halfway through, when one part works. The more snapshots you take, the closer the point you can go back to. If the last commit is from yesterday, going back means losing everything you did today.

2. When something breaks: go back

When the app stops working and I don't understand why, I don't ask Claude to fix the fix of the fix. I write:

Go back to how it was an hour ago. First save whatever isn't saved yet, and don't delete anything from the history: I want to be able to change my mind.

The sentence has three parts, and each one matters.

• “Go back to how it was an hour ago”: Claude looks at the project's history and finds the last commit before that moment. You can also say “to last night” or “to before you touched the login.”
• “First save whatever isn't saved yet”: changes that aren't in a commit are the most fragile. Claude puts them somewhere safe before it moves, with a commit or with git stash, which sets them aside so you can pick them up later.
• “Don't delete anything from the history”: this way Claude uses git revert, which doesn't delete the bad commits but adds a new one that undoes them. The whole history stays there: if you notice part of the last hour's work was good, you get it back.

The opposite is git reset --hard. It moves the project back and throws away the unsaved changes in the files, without going through the trash. Sometimes it's useful, but it's the command that loses work. That's why my sentence says “I want to be able to change my mind.”

When it's done, I ask for a check:

Tell me which commit you went back to, what you undid, and run the tests to see if it works now.

3. Before something big: a new branch

Redoing the login, changing the database, rewriting a whole page: these are jobs where things can go wrong halfway. Before I start, I write:

Do this work on a new branch. If it works and the tests pass, merge it into the main one. If it doesn't work, throw the branch away and go back to the good one.

A branch is a parallel version of the project. Claude works on it, makes its commits, and the main version, usually main, stays as it was. If the work holds up, it merges it: the changes from the branch go into the main version. If it doesn't work, it throws the branch away and you're back on the good point.

“The tests pass” is the part that matters. Without a check, “it works” only means it looks finished to Claude. If the project has no tests, at least ask it to start the app and tell you how it checked.

A branch changes the files in the same project folder, so one job at a time. If you want several Claude sessions in parallel, each on its own branch, you need worktrees: a separate folder for each branch. I cover them in the ALBERI guide (strikt.fit/alberi).

4. Bonus: Claude Code's checkpoints

Besides Git there's a smaller safety net, already built into Claude Code. Every time you send a message, Claude Code records the state of the files Claude edits with its own tools. These points are called checkpoints, and it makes them on its own.

To go back to one of these points, press Esc twice with the input empty, or type /rewind. If there's text in the input, double Esc just clears it. The list of messages you sent opens: pick the point and what to restore.

• Code and conversation: you go back to that point with both.
• Conversation only: the chat goes back to that message, the files stay as they are now.
• Code only: the files go back to how they were, the conversation stays.

The two code options only appear if Claude edited files after that point.

What they don't undo

• Terminal commands. If Claude deletes or moves a file with rm or mv, rewind won't bring it back.
• Changes made outside Claude Code: files you change by hand in the editor, or that another session changes, usually aren't tracked.

How long they last

Checkpoints are saved with the conversation. If you close the terminal and later resume the same session, you can still rewind. But they stay tied to that session: a new session starts without them. And by default Claude Code deletes the file copies about 30 days later, along with the session's old data.

That's why they don't replace Git. They're the session's undo button. Git keeps the project's real history.

5. A safety rule

Work that isn't saved yet is the work you can really lose, and the most common way is a reset. That's why every sentence tells Claude to save first. You can add:

Never use git reset --hard without asking me.

If you want it to apply every time, put it in the project's CLAUDE.md, the file Claude reads at the start of every session. It's still an instruction: Claude follows it, but it isn't a block. For a real block there's the deny list in the settings, which stops the command before it runs: I explain it in the JEV guide (strikt.fit/jev).

Common mistakes

• Working for hours without a commit: Git only goes back to saves that exist, so have Claude save before every job and whenever one part works.
• Having Claude fix the fix forever: after two failed tries, go back to the good point and start again with a clearer request.
• Relying on rewind for everything: it doesn't undo terminal commands or changes made outside Claude Code, so the real safety net is still Git.
• Letting a git reset --hard slip through: it throws away unsaved work, so ask for git revert and for a save first.
• Doing something big on the main version: start it on a new branch, so if it goes wrong you throw the branch away and lose nothing.
• Merging a branch without checking: run the tests before the merge, not after.

Checklist

• The project uses Git
• Commit before every job
• Commit when one part works
• To go back: git revert, no reset
• Big changes on a new branch
• Tests before merging the branch
• Rewind only for Claude's edits in the session

Frequently asked questions