Introduction

When you want to undo changes for one file in Git, the right command depends on which state you want to restore: the working tree, the staged version, or a version from another commit. Modern Git prefers git restore for this kind of file-level recovery because it is clearer than the older overloaded git checkout syntax.

Restore a File Back to HEAD

If you changed a file locally and want to throw away those unstaged edits, restore it from the last commit.

git restore path/to/file.txt

That updates the working tree copy of the file to match HEAD.

If the file also has staged changes and you want to throw those away too:

git restore --staged path/to/file.txt
git restore path/to/file.txt

The first command removes the staged changes from the index. The second resets the working tree copy.

Restore a File from a Different Commit

Sometimes you do not want HEAD; you want the file from some older commit.

git restore --source=abc123 path/to/file.txt

This copies the version of the file from commit abc123 into your working tree. It does not create a commit automatically. You can inspect the result, stage it, and commit if desired.

Older syntax for the same idea:

git checkout abc123 -- path/to/file.txt

This still works, but git restore --source=... is easier to read because it makes the intent explicit.

Revert Only Part of a File Interactively

If you want to keep some changes but discard others, use patch mode.

git restore -p path/to/file.txt

Git will show each hunk and ask whether to restore it. This is one of the safest ways to selectively undo parts of a file without rewriting everything manually.

You can do the same for staged hunks:

git restore --staged -p path/to/file.txt

That is especially useful when you staged too much and want to remove only part of the file from the next commit.

Understand Restore Versus Revert

git restore changes your working tree or index. git revert creates a new commit that undoes an older commit’s changes. Those are not the same operation.

If you want to undo the effect of a commit for just one file on a shared branch, a common pattern is:

git show badcommit -- path/to/file.txt

inspect the change, then restore or manually apply the desired version. git revert itself works at the commit level, not as a “revert only this file from the commit” shortcut.

That distinction matters because file-level cleanup in a local working tree is usually a restore problem, while history-preserving undo on a shared branch is a revert problem.

Use the Index and Working Tree Terms Precisely

File recovery gets much easier when you think in Git’s actual layers:

• working tree: what is on disk now
• index: what is staged
• 'HEAD: what the last commit contains'

Examples:

• discard unstaged edits: git restore file
• unstage while keeping working tree edits: git restore --staged file
• restore both staged and unstaged state to HEAD: do both commands

Once you know which layer is wrong, the command choice becomes straightforward.

Common Pitfalls

• Using git checkout from memory without remembering whether it changes branches or files makes recovery more error-prone.
• Restoring the working tree but forgetting the file is still staged leaves the next commit in an unexpected state.
• Using git revert when you only meant to fix a local file state mixes history operations with working-tree cleanup.
• Restoring from the wrong source commit can silently replace good work with an older version of the file.
• Skipping patch mode when only part of the file should be undone often leads to unnecessary manual reconstruction later.

Summary

• Use git restore for file-level undo in the working tree or index.
• Use --source=... when the desired file version comes from a different commit.
• Use patch mode for selective hunk-by-hunk restoration.
• Keep restore and revert conceptually separate: one changes local state, the other creates undo commits.
• Think in terms of working tree, index, and HEAD to choose the correct file-recovery command.