How to Roll Back a Bad AI Code Change With Git

If an AI coding assistant introduced a regression, you can roll back the change with Git—but the safest command depends on whether the edits are uncommitted, committed locally, or already shared. Start by checking the repository state, then undo only the change you intend to remove. This guide helps you choose the right recovery without overwriting unrelated work.

Practice Git workflows →

Check what Git would change before rolling anything back

Save open files, then check the current branch and working tree. Compare the changed files with the AI task you ran:

git status --short
git diff --stat
git diff
git diff --cached

The first diff shows unstaged tracked edits; the cached diff shows what is staged. Untracked files appear in status but not in either diff. Do not assume every current change came from the AI—your own earlier edits may be mixed in. For a detailed review workflow, see how to undo AI-generated changes safely.

Roll back uncommitted AI edits

To discard all unstaged edits in one tracked file and restore the version in the index, inspect it first and then restore that path:

git diff -- path/to/file
git restore -- path/to/file

If the file contains both wanted and unwanted edits, use git restore -p -- path/to/file to review individual hunks. To unstage a file without deleting its edits, use git restore --staged -- path/to/file. These commands address tracked files; inspect untracked files separately before deciding whether they should stay.

Avoid git clean or broad reset commands as a shortcut: they can remove work unrelated to the AI change. If you are unsure, make a backup copy before proceeding.

Roll back a local commit that has not been shared

If the AI change is the latest commit and has not been pushed, first check whether your working tree is clean. To remove that commit but keep its changes staged for editing, use:

git status
git reset --soft HEAD~1

This moves the current branch back one commit while retaining the commit's changes in the index. Review what remains before deciding whether to edit or discard it. If other people may have based work on the commit, do not rewrite it; use a revert instead.

Revert a bad change that has been pushed

For a commit already pushed to a shared branch, add a new commit that reverses it:

git log --oneline
git revert <commit-id>

Review the commit ID carefully. If the revert reports conflicts, resolve them, test the app, and inspect the resulting diff before pushing. If the assistant's work spans several commits, review each one and coordinate with collaborators rather than guessing a range or force-pushing over their work.

Test the recovered code and create a clean checkpoint

Run the failing test or build, and check the feature that exposed the regression. Before committing or pushing, review what is staged and what remains:

git diff
git diff --cached
git status