Introduction

Undoing changes in selected files is a common Git task when only part of your working tree should be discarded. The correct command depends on file state: unstaged, staged, or already committed. Using targeted restore commands prevents accidental loss and avoids heavy operations that affect unrelated work.

Check State Before Undoing Anything

Start by inspecting what changed and where it is staged.

git status
git diff
git diff --staged

This step prevents using the wrong undo command for the wrong state.

Undo Unstaged Changes in Specific Files

If a file is modified in working tree but not staged, restore it from current HEAD.

git restore src/config.yml
git restore app/main.py

Only listed files are reverted. Other local edits remain untouched.

Unstage a File but Keep Its Content

If a file is staged and you want to keep its edits locally:

git restore --staged src/config.yml

This removes the file from index while preserving working tree modifications.

Discard Both Staged and Unstaged Edits for One File

To fully reset one file to current commit content:

git restore --source=HEAD --staged --worktree src/config.yml

This is destructive for that file. Verify with git diff first.

Restore File from an Older Commit

Sometimes you want a known past version, not current HEAD.

git restore --source=abc1234 -- app/main.py
git add app/main.py
git commit -m "Restore app/main.py from abc1234"

This creates an explicit forward commit and keeps history safe for collaborators.

Hunk-Level Undo for Partial Cleanup

When only part of a file should be undone, use interactive patch mode.

git restore -p app/main.py

Git shows each hunk and lets you choose what to discard. This is useful when one file contains both keep and discard edits.

Already Committed and Pushed Changes

If bad changes are already shared, prefer a new corrective commit over history rewrite on shared branches.

git restore --source=HEAD~1 -- src/config.yml
git add src/config.yml
git commit -m "Revert config file to previous state"

This keeps team history linear and avoids force push risk.

Recovery If You Undo Too Much

If you accidentally discard useful work, inspect reflog quickly.

git reflog
git checkout -b recover-work <reflog-sha>

Reflog can often recover states even after destructive file restore commands.

Practical Safe Workflow

A repeatable sequence reduces mistakes:

1. inspect status and both diffs
2. choose smallest scope command
3. verify status again
4. run tests if behavior changed
5. commit intentional final state

Small targeted undo steps are safer than one broad reset command.

Team Practices for Clear History

In collaborative repos, separate cleanup commits from feature commits when possible. One commit can restore files to baseline, and another can contain functional changes. This makes reviews easier and future reverts lower risk.

Also document unusual restores in commit messages, especially when restoring from non-head commits.

Safer Collaboration Defaults

On shared branches, prefer additive fix commits instead of force rewrites whenever possible. This keeps teammate history stable and reduces accidental rollback of unrelated work.

Common Pitfalls

A common pitfall is using repository-wide reset commands when only one file needed rollback.

Another issue is confusion between staged and unstaged states, which leads to unexpected kept or discarded changes.

Teams also rewrite published history unnecessarily when a forward fix commit would be safer and simpler.

Summary

• Choose undo command based on file state: unstaged, staged, or committed.
• Use git restore for precise file-level recovery.
• Use patch mode for hunk-level selective undo.
• Prefer forward corrective commits on shared branches.
• Check git status and diffs before and after each undo operation.