The "Undo" Toolkit: Reversing AI Mistakes

The AI just rewrote half your file and it's completely wrong. You haven't committed anything yet. This is the simplest undo — just throw it all away and go back to your last save point.

The fix is simple -- one command wipes the slate clean and takes you back to your last commit:

git restore .              # Discard edits to tracked files
git restore src/bad_file.py  # Discard a single file

One blind spot: git restore only rewinds files Git already tracks. Brand-new files the AI scaffolded are untracked, so they survive it. Preview the leftovers with git clean -n (a dry run), then delete them with git clean -fd.

And one more trick for the road — restore doesn't have to stop at "the last commit." The most common real-world rescue is one file, from an older commit: the AI broke src/parser.py three commits ago and you only just noticed. No reset, no history surgery:

git restore --source=HEAD~3 src/parser.py
# The file's content is now as it was 3 commits ago;
# everything else stays untouched. Review it, then commit.

In VS Code, you don't need the terminal for this. In the Source Control panel, hover over the file you want to discard under "Changes" and click the curved arrow icon. To discard ALL changes at once, click the curved arrow next to the "Changes" header. You can also right-click any file and choose "Discard Changes".

You hit git add . a bit too quickly and staged files you didn't mean to include. No worries — unstaging is completely harmless and doesn't touch your code.

No worries -- unstaging is a safe operation that simply moves a file back out of the staging area:

git restore --staged src/bad_file.py
# Older equivalent: git reset HEAD src/bad_file.py

In VS Code, this is a one-click fix. In the Source Control panel, look under "Staged Changes", hover over the file you want to unstage, and click the − (minus) button. The file moves right back to "Changes":

VS Code Expand

Try It: Unstage Dangerous Files

You just committed — and immediately realized you forgot a file, or there's a typo in the message. Instead of creating a messy "oops" commit, you can quietly fix the last one.

Instead of creating a whole new commit, you can tack the missing file onto the one you just made:

git add src/forgotten_file.py   # Stage the missed file
git commit --amend --no-edit     # Add it to the last commit

# Or just fix the message:
git commit --amend

In VS Code, click the dropdown arrow next to the Commit button and select "Commit (Amend)". This adds your newly staged files to the last commit without needing the terminal. You can also find this under the ... menu → Commit → Commit Staged (Amend).

Sometimes the AI experiment was a dead end — three commits deep, and none of it is salvageable. If you haven't pushed yet, you can erase those commits entirely and start fresh.

This is where the nuclear option comes in. A hard reset rolls your branch back as if those commits never happened:

git reset --hard HEAD~3   # Remove last 3 commits + all changes

"Remove," not quite "delete": the commits vanish from your branch, but Git keeps them around for ~30 days and the reflog (section 4.9) can bring them back. The truly unrecoverable loss is different — see the --hard card below.

The "Safer" Resets

This is the "oh no" moment — you pushed a bad commit and your teammates already pulled it. You can't erase history, but you can create a new commit that perfectly reverses the damage.

The WRONG Solution: You cannot use git reset. It rewrites history that others have, causing repository divergence.

The RIGHT Solution: Create a new commit that undoes the bad commit. This is a revert.

Here's how to create that revert commit in the terminal:

git log --oneline           # Find the hash: a1b2c3d
git revert --no-edit a1b2c3d # Create an inverse commit
git push                    # Push the revert

Without --no-edit, Git opens your editor so you can customize the revert message — fine once you expect it, startling the first time (especially if that editor turns out to be vim).

Notice that you're not erasing anything -- you're adding a new commit on top that reverses the damage:

VS Code has this built in too. Open the ... menu in the Source Control panel -- this is your gateway to all advanced Git operations. From here you can access Commit, Changes, Pull, Push, Branch, Stash, and more:

VS Code Expand

For reverting pushed commits, use the Source Control Graph: right-click any commit and select "Revert Commit" to create the inverse commit safely.

You rewrote local history with a reset or amend — and now Git refuses to push because local and remote have diverged. This is the emergency tool: a force push with a built-in safety net.

You have two flavors of force push, and picking the right one matters a lot:

One subtlety: the lease compares the remote against what you last fetched — so run git fetch first, review what changed on the remote, and only then push.

Try It: Reset and Force Push

Before moving to advanced topics, here's a quick-reference matrix summarizing every undo technique and when to use it:

Try It: The Undo Toolkit

You (or the agent) checked out an old commit hash to see how the code looked before a refactor — and the terminal barks back: "You are in 'detached HEAD' state." It sounds like an injury. It isn't. It's Git telling you exactly where you are: in the past.

Normally, HEAD points at a branch, and the branch moves forward with every commit. When you check out a commit hash directly, HEAD points at that commit instead — no branch is along for the ride. Looking around is completely safe:

git log --oneline        # Find the commit you want to visit
git checkout HEAD~2      # Detach HEAD two commits back
cat src/app.py           # Look around — reading is 100% safe

The catch is committing while detached. Any commits you make there belong to no branch — the moment you switch away, nothing points at them anymore and they become orphaned. They don't disappear instantly (the reflog still remembers them — see section 4.9), but they vanish from git log and real Git will eventually garbage-collect them.

There are exactly two escape hatches, and choosing is easy:

# Made something worth keeping? Put a branch under your feet:
git switch -c inspect-v02

# Just sightseeing? Go back to the present:
git switch main

Try It: Time-Travel and Escape

The agent ran git reset --hard and the log now looks like two days of work never happened. Before you panic: those commits are not gone. Git keeps a private journal of every place HEAD has ever been — the reflog — and it's about to save your week.

git log only shows commits reachable from your branches. The reflog shows everywhere HEAD has moved, reachable or not. Here's how to read it:

git reflog

a9f8e21 HEAD@{0}: reset: moving to HEAD~2         <- where you are NOW
4c7d3b9 HEAD@{1}: commit: feat: add caching layer <- one move ago (the "lost" work!)
8e2f1a0 HEAD@{2}: commit: feat: add ranking algorithm
1d0c5f4 HEAD@{3}: commit (initial): Initial commit

HEAD@{n} means "where HEAD was n moves ago" — HEAD@{0} is now, HEAD@{1} is one move back. Each line also shows the short hash, so you have two ways to name any point in time. Pick your recovery recipe:

# 1. Undo the reset entirely — move the branch back:
git reset --hard HEAD@{1}

# 2. Rescue a single lost commit onto your current branch
#    (cherry-pick gets its own section in 5.4):
git cherry-pick 4c7d3b9

# 3. Inspect first — park a rescue branch on the lost commit:
git switch -c rescue 4c7d3b9

Try It: Rescue Lost Commits

The reflog answers "where did my commits go?" Its sibling question — "which commit broke this?" — has its own tool: git bisect binary-searches your history. Mark one commit as bad and one as good, and Git checks out midpoints for you to test — 1,000 commits take ten rounds, not a thousand. In the agent era this is the tool for "somewhere in the bot's forty commits, the tests started failing."

Try It: Find the Bad Commit