Git First Recovery — Claude Code Guide

Stop the avalanche first

After an unsuccessful AI edit, do not immediately ask Claude to “fix everything.” First establish the actual scope of the problem through Git: the active branch, changed files, diff, and latest commits.

A minimal rollback is safer than editing again on top of a chaotic diff. Small milestone commits make recovery cheaper.

git status
git diff -- path/to/file
git diff
git log --oneline -3

Recovery depends on where the changes are

State	Approach
Working files	Review the diff and, if needed, cautiously use `git restore`
Staging area	First run `git restore --staged`, then assess the file
Bad commit in shared history	Create a new commit with `git revert`
Bad local commit	Consider reset only if the team has not seen the history yet
Confused branch	Create a new branch from a clean base

Minimal Git-first recovery

Stop new AI edits.
Check git status and review suspicious diff fragments.
Separate the needed changes from the unnecessary ones.
Choose the smallest safe rollback method.
Run the relevant tests.
Check the diff again.
Give Claude a new narrow task with explicit boundaries.

Cautious recovery of a working file

git restore path/to/file
git status
git diff

A clean base for another attempt

The old branch can remain a source of individual useful ideas, but it is better to start a new implementation from a clean base when the previous diff is already difficult to explain.

git switch -c refund-refactor-retry main

External effects do not roll back with Git

Git restores files and history, but does not undo a database migration.
Rolling back code does not reverse an external call or a deployment that has already run.
For shared history, git revert is usually safer than rewriting it.
Before git restore, make sure the unsaved changes are truly unnecessary.

Canonical lesson source · JavaRush

Open JavaRush material