Three Git commands you will encounter for "going back". Memorize which is which.

• git revert <commit> — safe. Creates a NEW commit that undoes the changes of the named commit. History is preserved. Always reversible.
• git checkout <commit> -- <file> — safe. Restores the file to a previous state. Other files untouched. Working tree updated.
• git reset --hard <commit> — destructive. Moves the branch pointer back AND wipes all uncommitted changes. No recovery without reflog (which beginners do not know how to use under stress).

Rule of thumb: when you hear "hard" in a Git command name, you are about to lose data if you do not know exactly what you are doing.

This is the path 90 percent of beginners should default to. In GitHub Desktop:

1. Click the History tab (left side).
2. Find the commit you want to undo.
3. Right-click → "Revert this commit".

A new commit appears that undoes the targeted commit. Your history is preserved, you can revert the revert if you change your mind, and nothing else is touched. Same in VS Code's Source Control history panel.

If you are inside a Claude Code session and want to undo the last few changes (code AND conversation), use the built-in command:

/rewind

It is also aliased as /checkpoint. Claude Code automatically creates checkpoints before significant edits, and /rewind lets you jump back to any of them. Both code and conversation reset to that point.

Important nuance from Vincent Qiao's blog post on /rewind: "git is long-term version management, /rewind is instant undo within a session. They complement each other. Best practice: Commit at every important milestone, then use /rewind for fine-grained rollbacks between commits."

So /rewind is great for "the last AI edit was bad, go back two prompts". Git is the fallback for anything bigger than a session.

If you do want to drive Git from the prompt, be specific. Never vague.

Bad:

"Claude, undo that"

Good:

"Run git diff HEAD~1 first so we both see what is in the last commit. Then if the changes are wrong, run git checkout HEAD~1 -- src/auth.ts to restore that one file."

Or even more conservative:

"Run git log --oneline -5. Don't change anything yet. Tell me which commit you would revert and why."

This forces the AI to read state before acting. It also keeps you in the loop on what is about to happen. The Issue 17190 case was specifically a vague "undo" prompt that the AI translated into the destructive default. Specific prompts kill that path.

Make a throwaway branch and try each path so the muscle memory is there before you need it:

git checkout -b throwaway-rollback-test
echo "test1" > test.txt && git add . && git commit -m "test1"
echo "test2" > test.txt && git add . && git commit -m "test2"

# Try revert (safe)
git revert HEAD --no-edit
cat test.txt  # back to "test1"

# Clean up
git checkout main && git branch -D throwaway-rollback-test

Then in a Claude Code session, ask "what is /rewind?" — see how the assistant explains it. Run it once with a tiny made-up edit to feel the UX. Now you have all three paths in your hands.

So the AI cannot footgun you on this:

## Rollback policy

Never run `git reset --hard` or `git clean -fd` to revert uncommitted changes.
For undoing committed work, use `git revert` (creates a new commit) or
`git checkout <commit> -- <file>` (restores a single file). For session-level
undo of recent edits, prompt the user to use /rewind. If asked to "undo" or
"roll back" without specifics, ask the user which commit or file before
running anything.

This rule alone stops the worst-case Issue 17190 scenario across every project where the CLAUDE.md is loaded.