How to Review and Revert AI-Generated Changes with Git

AI coding assistants can change a project much faster than most beginners can review it.

A single request may update several files, create a new configuration file, install a dependency, rename a function, and modify documentation. Even when the result appears to work, some of those changes may be unnecessary or unrelated to the task.

Git gives you a way to slow the process down.

It can show which files changed, display the exact lines that were added or removed, separate staged and unstaged edits, and restore selected files when the result is not worth keeping.

The goal of this guide is not to memorize every recovery command. It is to build a repeatable review process that keeps AI-generated changes understandable.

Version note: Git commands used in this guide are widely supported, but exact output and editor integration may vary. Before publication, compare command behavior with the current official Git documentation for the Git version used in your tutorial environment.

What You Will Learn

By the end of this guide, you should be able to:

• create a clean checkpoint before an AI task;
• inspect changed, new, and deleted files;
• review unstaged changes with git diff;
• review staged changes with git diff --staged;
• identify unrelated AI-generated edits;
• restore one unwanted file;
• unstage a file without deleting its contents;
• discard all uncommitted changes only when you fully understand the result;
• reverse a committed change with a new commit;
• choose between keeping, editing, reverting, and discarding a result.

This article assumes that you already understand:

• working directory;
• staging area;
• commits;
• local and remote repositories;
• basic commands such as git status, git add, and git commit.

Start from a Known State

The safest time to review an AI change is before the AI makes it.

That may sound strange, but review becomes much easier when the repository begins in a clean, known state.

Open the project:

cd ~/projects/vibe-coding-practice

Check the current status:

git status

The ideal result is a message indicating that the working tree is clean.

That means:

• no tracked files have uncommitted edits;
• no staged changes are waiting;
• no untracked files are present;
• the latest commit is your current checkpoint.

Review recent commits:

git log --oneline -5

You should recognize the latest commit as a valid project state.

If the working tree is not clean, stop before starting the AI task.

Run:

git diff

Then decide whether the existing work should be:

• completed and committed;
• kept unfinished;
• moved to a separate branch;
• discarded;
• postponed until after the AI task.

Do not mix unknown existing edits with a new AI-generated change.

Define the Expected Change Before Asking the AI

Before using GitHub Copilot or Claude Code, write down the expected scope.

For example:

Task:
Add an “AI Review Checklist” section to README.md.

Allowed files:
- README.md

Not allowed:
- No new files
- No dependency changes
- No edits to JavaScript files

Verification:
- Review the Markdown output
- Confirm that only README.md changed

This gives you a review baseline.

After the AI finishes, you can compare the result with the original task.

Without a defined scope, almost any change can look reasonable.

With a defined scope, unrelated changes become easier to identify.

Use git status as the First Review

After the AI completes its work, do not rely only on its summary.

Run:

git status

This command shows the project state at a high level.

You may see files listed as:

• modified;
• deleted;
• renamed;
• untracked;
• staged.

For example:

Changes not staged for commit:
  modified:   README.md
  modified:   package.json

Untracked files:
  review-notes.txt

If the task was limited to README.md, the other two files require investigation.

Do not stage everything simply because the AI said the task was complete.

Questions to Ask After git status

Review the file list and ask:

• Did the AI modify only the expected files?
• Did it create temporary files?
• Did it change package configuration?
• Did it delete anything?
• Did it create a file containing logs or secrets?
• Did it rename a file without being asked?
• Are any generated files too large or unnecessary?

git status tells you where to look next.

Review Unstaged Changes with git diff

Run:

git diff

This displays the differences between the working directory and the staged version.

If nothing is staged, it usually shows all tracked file edits since the last commit.

You may see output similar to:

-Old line
+New line

A line beginning with - was removed.

A line beginning with + was added.

The surrounding lines provide context.

Review One File at a Time

When several files changed, inspect them individually:

git diff README.md

Then:

git diff package.json

This is easier than reviewing a large combined diff.

For each file, ask:

• Does this change support the requested task?
• Is the change smaller than necessary?
• Did the AI reformat unrelated content?
• Did it remove comments or error handling?
• Did it change a dependency version?
• Did it alter a script or build command?
• Can I explain every meaningful change?

If the answer is no, do not commit yet.

Review New Untracked Files

git diff does not always display untracked file contents because Git is not yet tracking them.

List the directory:

ls -la

Open the new file in VS Code or print it in the terminal:

cat review-notes.txt

Before adding an untracked file, decide whether it belongs in the repository.

Common unwanted untracked files include:

• temporary notes;
• debug output;
• logs;
• generated caches;
• environment files;
• local configuration;
• editor metadata;
• downloaded data;
• credentials.

Never add a file simply because the AI created it.

Check for Secret or Sensitive Data

Before staging anything, scan the changed files for sensitive information.

Look for:

• API keys;
• access tokens;
• passwords;
• email addresses;
• private URLs;
• production database strings;
• local machine usernames;
• company names;
• customer data;
• internal project identifiers.

A generated .env file deserves special attention.

For example:

.env

Do not commit it automatically.

Check whether .gitignore excludes it:

cat .gitignore

Even when a secret file is ignored, confirm that no credential was copied into source code, documentation, or terminal logs.

If a real secret was exposed, removing the line is not always enough. The credential may need to be rotated.

Compare the Result with the Original Request

A code change can be valid and still be wrong for the task.

Suppose you asked the AI to add input validation.

The AI may also:

• rename the function;
• change the return type;
• add a third-party package;
• restructure the directory;
• rewrite comments;
• update formatting across the file.

Some of those changes may be reasonable in isolation, but they increase review cost and risk.

A useful review question is:

What is the smallest change that satisfies the requirement?

If the AI result is much larger than that, consider editing it down or asking for a more focused attempt.

Run the Project Before Staging

A visually reasonable diff does not prove that the change works.

Use the project’s normal verification method.

For a simple JavaScript file:

node copilot-practice.js

For a project with tests:

npm test

For a project with a development server:

npm run dev

Only run commands you understand and that belong to the project.

Do not approve a generated command merely because the AI recommends it.

Check:

• does the application start;
• does the intended behavior work;
• do existing tests still pass;
• does an unrelated feature fail;
• are new warnings present;
• did a dependency installation change lock files;
• does the result work only for the example input?

Testing gives you evidence. The AI’s explanation does not.

Stage Only the Files You Intend to Keep

After reviewing the changes, stage specific files.

For example:

git add README.md

Avoid:

git add .

until every changed and untracked file has been reviewed.

Run:

git status

You should now see README.md under staged changes.

Other files may remain unstaged.

This is useful when the AI produced one good change and one unwanted change.

Review Staged Changes Separately

Run:

git diff --staged

This shows exactly what will enter the next commit.

That is your final pre-commit review.

Ask:

• Does the staged diff contain only the intended change?
• Did I accidentally stage a generated file?
• Is the commit focused on one purpose?
• Are any credentials visible?
• Does the commit message I plan to use match the diff?

A clean staged diff should tell one clear story.

Unstage a File Without Deleting It

Suppose you staged package.json accidentally.

Run:

git restore --staged package.json

This removes the file from the staging area.

It does not delete the file’s working-directory changes.

Check:

git status

The file should now appear as modified but unstaged.

This distinction matters:

Unstage = keep the edits, remove them from the next commit
Restore = discard the edits and return to a previous version

Do not confuse the two actions.

Restore One Unwanted File

Suppose Claude Code changed package.json, but the task did not require dependency changes.

Review the file first:

git diff package.json

If you are certain the change should be discarded, run:

git restore package.json

This restores the working file to the staged or last committed version, depending on the current state.

For a normal unstaged change, it usually returns the file to the last committed version.

The uncommitted edits are lost.

Confirm the result:

git status

Then inspect the remaining changes:

git diff

Use file-level restore only after confirming that the file contains no manual work you need.

Restore Several Unwanted Files

You may restore multiple named files:

git restore package.json package-lock.json

This is safer than restoring the entire project because the target is explicit.

Review each file before doing so.

Package files often change together, so both may need to be restored when an unwanted dependency was added.

Remove an Untracked File Carefully

git restore does not remove untracked files because Git has no committed version to restore.

Suppose the AI created:

debug-output.txt

Open and inspect it first.

If it is truly unnecessary, remove it using the file manager or a direct command:

rm debug-output.txt

The rm command deletes the file.

There is no Git recovery for an untracked file that was never committed.

Check the filename and location carefully before running it.

Avoid broad commands that delete many files until you fully understand their scope.

Discard All Unstaged Tracked Changes

Git can restore all tracked files in the current directory:

git restore .

The period refers to the current directory.

This discards all unstaged edits to tracked files under that directory.

Use it only when:

• you reviewed the entire diff;
• no manual work needs to be kept;
• the repository is in the correct directory;
• you are intentionally abandoning the AI result.

Before running it:

pwd
git status
git diff

Then pause and confirm that every listed edit can be lost.

For beginners, restoring individual files is usually safer.

Review Changes in VS Code

Git commands are not the only review option.

VS Code’s Source Control view can display:

• modified files;
• staged files;
• untracked files;
• line-by-line diffs;
• staging controls;
• discard controls.

Select a changed file to compare the old and new versions side by side.

This can be easier for large edits.

However, the same safety rules apply.

Before using a graphical discard button:

• confirm the selected file;
• confirm whether the change is staged or unstaged;
• inspect the diff;
• understand whether the action is reversible.

A friendly interface does not make a destructive action safer.

Commit Only the Verified Change

When the staged diff is correct, create a commit:

git commit -m "Add AI review checklist to README"

Then check:

git status
git log --oneline -3

The commit should appear at the top of the history.

The working tree may still contain unstaged unwanted changes.

If so, review and restore them separately.

A commit does not automatically clean every file. It records only the staged changes.

Reverse a Committed Change with git revert

Sometimes an AI-generated change is committed and later found to be wrong.

If the commit has already been shared or pushed, git revert is often a safer beginner option than rewriting history.

First, identify the commit:

git log --oneline

You may see:

f3a91c2 Add AI review checklist to README
c21f8a0 Document Claude Code setup

To reverse the first commit while preserving history:

git revert f3a91c2

Git creates a new commit that applies the opposite change.

This produces a history like:

A ── B ── C ── D

Where:

C: Add AI review checklist
D: Revert "Add AI review checklist"

The original commit remains visible.

This is valuable in shared repositories because the history clearly shows what happened.

Review After Revert

Run:

git status
git log --oneline -5

Then inspect the affected files.

If the revert created a conflict, stop and review the conflicting sections instead of repeatedly rerunning the command.

When Not to Use History-Rewriting Commands

Git includes commands that can move branch history or discard commits.

Some tutorials recommend commands such as:

git reset --hard

This command can permanently discard local changes and move history.

It is not appropriate as a casual beginner recovery tool.

Do not use history-rewriting commands unless you understand:

• which commit the branch will move to;
• which working-directory changes will be lost;
• whether the commit was already pushed;
• whether other collaborators depend on the current history;
• how to recover if the target is wrong.

For this beginner workflow, prefer:

• git restore for unwanted uncommitted file changes;
• git restore --staged for accidental staging;
• git revert for reversing a committed change while preserving history.

These commands make the intent clearer.

Review a Multi-File AI Change

Suppose Claude Code was asked to add input validation and changed:

app.js
app.test.js
package.json
README.md

Use this process.

Step 1: Check the File List

git status

Step 2: Review Each File

git diff app.js
git diff app.test.js
git diff package.json
git diff README.md

Step 3: Categorize the Changes

For example:

app.js       Required implementation
app.test.js  Required verification
package.json Unexpected dependency
README.md    Useful but unrelated

Step 4: Keep Only the Focused Change

Restore the unwanted dependency edit:

git restore package.json

Decide whether the README update belongs in a separate commit.

Stage the implementation and test:

git add app.js app.test.js

Review:

git diff --staged

Commit:

git commit -m "Validate empty task titles"

Then stage the documentation separately if it is still useful:

git add README.md
git diff --staged
git commit -m "Document task validation behavior"

This produces a clearer history than combining everything into one commit.

Recognize Unrelated AI Changes

AI-generated changes often expand beyond the request in predictable ways.

Watch for:

• dependency additions;
• formatting across entire files;
• renamed functions;
• new abstractions;
• deleted comments;
• changed error messages;
• altered configuration;
• new scripts;
• moved files;
• documentation updates;
• generated lock files;
• test rewrites.

Not every extra change is wrong.

The question is whether it is necessary, understood, and appropriate for the current commit.

When unsure, keep the requested change small and leave broader refactoring for a separate task.

Ask the AI to Explain the Diff, Then Verify It

You may ask the coding assistant:

Summarize every changed file, explain why each change was necessary, and identify any new dependencies. Do not modify the project.

This can help organize the review.

However, compare the answer with:

git status
git diff

The AI may:

• omit a file;
• misunderstand its own change;
• describe intended behavior instead of actual behavior;
• overlook a generated configuration file.

Git shows the repository evidence.

The AI provides commentary.

Do not confuse the two.

A Senior-Style Review Checklist

Before accepting AI-generated changes, ask:

Scope

• Does the change match the request?
• Did unrelated files change?
• Is the implementation larger than necessary?

Behavior

• Does the requested feature work?
• Are edge cases handled?
• Did existing behavior change unexpectedly?

Structure

• Is the code located in the correct file?
• Does it follow existing project patterns?
• Was an unnecessary abstraction introduced?

Dependencies

• Were packages added?
• Are they required?
• Did lock files change?
• Are the packages appropriate for the project?

Security and Privacy

• Were secrets added?
• Did file permissions change?
• Was sensitive logging introduced?
• Does the code trust unvalidated input?

Verification

• Were tests added or updated?
• Do existing tests pass?
• Can the behavior be reproduced manually?
• Does the staged diff match the planned commit?

You do not need to be an expert in every language to ask these questions.

They help you review intent, scope, and evidence.

A Safe AI Review Workflow

Use this sequence after every meaningful AI task.

1. Inspect the Repository

git status

2. Review the Changes

git diff

3. Inspect New Files

ls -la

4. Run the Relevant Verification

npm test

Use the command appropriate to the project.

5. Restore Unwanted Files

git restore path/to/unwanted-file

6. Stage Specific Files

git add path/to/verified-file

7. Review the Staged Diff

git diff --staged

8. Commit

git commit -m "Describe the verified change"

9. Confirm the Final State

git status
git log --oneline -3

This workflow turns Git into a review boundary around the AI assistant.

Verify Your Understanding

Before moving to the final article in this series, confirm that you can explain and use:

• git status to list changed files;
• git diff to review unstaged tracked changes;
• git diff --staged to review the next commit;
• git restore --staged filename to unstage without deleting edits;
• git restore filename to discard an unwanted uncommitted tracked-file change;
• git revert commit-id to reverse a committed change with a new commit;
• file-by-file staging;
• separate commits for separate purposes;
• Git review as evidence rather than relying on the AI summary.

Also remember:

A clean AI response is not the same as a clean Git diff.

Further Reading

If you want to go beyond basic Git diffs and develop a more systematic approach to reviewing AI-generated code, my book, Practical Code Review in the Age of AI: Review Like a Senior, expands on many of the ideas introduced in this guide. It covers practical review habits, risk-based thinking, maintainability, testing, security, and the judgment required to evaluate code produced by AI coding assistants. You can find the book on Amazon: Practical Code Review in the Age of AI: Review Like a Senior. 

Conclusion

Git gives you a controlled way to evaluate AI-generated changes.

git status shows which files changed. git diff shows the exact edits. The staging area lets you select only the files you trust. git restore can discard unwanted uncommitted changes, while git revert can reverse a committed change without hiding the history.

The safest process is to start from a known checkpoint, define the expected scope, review every changed file, test the result, and commit only the verified portion.

The next and final article in this setup series will combine everything into one complete workflow. We will move from opening a WSL project and checking Git status to choosing an AI tool, reviewing the result, testing it, committing it, and pushing the verified change to GitHub.

Frequently Asked Questions

What is the difference between git restore and git revert?

git restore is commonly used to discard uncommitted file changes.

git revert creates a new commit that reverses an earlier commit while preserving the original history.

Can Git recover an untracked file after I delete it?

Usually not.

If a file was never added or committed, Git has no stored version to restore. Inspect untracked files carefully before deleting them.

Should I use git reset --hard to undo AI changes?

Not as a routine beginner workflow.

It can discard local work and move history. Prefer file-level git restore, unstaging with git restore --staged, or history-preserving git revert unless you fully understand the consequences.

• Next article: Your First Safe Vibe Coding Workflow