Introduction

Restoring one file to an earlier Git revision is a common task during bug fixes, refactors, and incident response. The important detail is deciding whether you want a local workspace change only or a new commit that records the rollback in history. Once that choice is clear, the correct command sequence is straightforward and safe.

Choose the Right Goal First

Before typing commands, decide which outcome you need.

• You want to preview or test an old version in your working tree.
• You want to commit a rollback of one file on your current branch.
• You want to undo a bad commit in shared history without rewriting branch history.

Git has commands for all three, but they are not interchangeable.

Restore a File in Working Directory Only

If you want the file content from an old commit but do not want to create a commit yet, use git restore with a source revision.

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

This updates your working tree copy of that file. If you also want it staged immediately, add --staged.

git restore --source=abc1234 --staged --worktree -- path/to/file.txt

Older Git versions used git checkout for this task.

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

Both approaches replace that file with the chosen historical snapshot.

Find the Correct Revision for the File

A common mistake is restoring from the wrong commit hash. Inspect file history first.

git log --oneline -- path/to/file.txt

If you need only deletion-related history:

git log --diff-filter=D -- path/to/file.txt

To inspect what the file looked like at a specific commit without modifying your tree:

git show abc1234:path/to/file.txt

This quick check prevents accidental rollback to an unrelated intermediate state.

Commit a File-Level Rollback

If you want branch history to record the change, restore the file, stage it, and commit.

git restore --source=abc1234 -- path/to/file.txt
git add path/to/file.txt
git commit -m "Restore file.txt to state from abc1234"

This is usually the safest pattern in team branches because it creates an explicit audit trail.

Revert a Commit Versus Restore a File

git revert and git restore solve different problems.

• git restore copies file content from another revision.
• git revert creates a new commit that inverses a full commit.

If a bad commit changed many files but you only want to undo one file, use file restore plus commit. If you need to reverse the entire commit in shared history, git revert is usually the right choice.

git revert f00ba47

For merge commits, git revert has additional parent selection complexity, so file-level restore is often simpler when scope is limited.

Recover a Deleted File

If file was deleted and you want it back, identify the delete commit and restore from its parent state.

1git log --diff-filter=D --oneline -- path/to/file.txt
2git restore --source=abc1234^ -- path/to/file.txt
3git add path/to/file.txt
4git commit -m "Restore deleted file.txt"

You can also restore from any known commit where the file existed.

git restore --source=9f9e9d9 -- path/to/file.txt

Compare Before Committing

After restoration, inspect differences before creating commit.

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

This is useful when file has mixed formatting or generated sections and you only intended targeted rollback.

Safer Workflow in Shared Repositories

In collaborative branches, avoid destructive history edits unless coordinated. Prefer additive commit-based rollback.

Recommended sequence:

1. create short-lived branch for rollback
2. restore file from specific revision
3. run tests and lint
4. commit with clear message
5. open pull request with rationale

This keeps review and blame history clear for future debugging.

Common Pitfalls

A frequent pitfall is mixing up restore and reset commands and unintentionally affecting index state. Another is restoring from a commit hash without verifying file content first, which can pull in an older-than-intended version. Teams also often forget to run tests after rollback, especially when file interacts with config, serialization, or migrations. Finally, rewriting remote shared history to fix one file usually creates more risk than a normal rollback commit.

Summary

• Decide first whether you need local restore or committed rollback.
• Use git restore --source=... -- path for file-level retrieval.
• Check file history and preview content before restoring.
• Commit restored file for safe collaboration and traceability.
• Prefer additive rollback commits over destructive history rewrites on shared branches.