Introduction

Recovering a deleted file in Git is usually easy if you know how to locate the correct historical revision. The key steps are identifying when the deletion happened, restoring the file content from a known commit, and deciding whether to keep recovery local or commit it to branch history. A structured workflow prevents restoring the wrong version and avoids unsafe history edits.

Understand the Recovery Scenario

First identify which situation you are in.

• File was deleted locally but not committed yet.
• Deletion was committed on current branch.
• Deletion happened in older history and you need a specific version.
• File name changed before deletion, so path history is nontrivial.

Each case has a slightly different command sequence.

Recover an Uncommitted Local Deletion

If file was deleted from working tree and you have not committed, restore from HEAD.

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

Older equivalent command:

git checkout -- path/to/file.txt

This restores current committed version and drops local deletion.

Find the Commit That Deleted the File

For committed deletions, inspect history filtered to delete events.

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

That gives the deletion commit hash. To inspect file-related history in more detail:

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

If file was renamed previously, use follow mode on one path segment.

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

Use this when straightforward path history appears incomplete.

Restore from the Commit Before Deletion

If commit abc1234 deleted the file, restore from its parent revision.

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

Then stage and commit recovery.

git add path/to/file.txt
git commit -m "Restore deleted file.txt"

This approach preserves branch history clearly and is safe in shared repositories.

Restore from a Specific Historical Version

Sometimes you do not want the immediately previous version. You want content from a particular commit.

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

Preview file content before restore if needed.

git show 9f9e9d9:path/to/file.txt

This avoids accidental restore of outdated or partially migrated content.

Recover Without Creating a Commit Yet

If you want to compare or test recovered content first, restore into working tree and inspect diff.

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

Commit only after validating build, tests, and runtime behavior.

Restore Multiple Deleted Files

If a commit removed many files and you need several back, restore each explicitly or restore a directory path.

git restore --source=abc1234^ -- src/legacy/

Be careful with broad restores because they may bring back files you did not intend to recover.

Use revert When Deletion Commit Should Be Inverted

If the deletion commit should be undone as a whole in shared history, git revert is often cleaner than file-by-file restore.

git revert abc1234

This creates a new commit that inverses prior commit changes. It is safer for collaboration than rewriting history with reset and force-push.

Verify Recovery Before Pushing

Always verify what exactly is being recovered.

git status
git diff --staged
git log --oneline -n 5

Run tests and linters if the file is executable source, configuration, or migrations.

Advanced Recovery: Reflog and Lost Commits

If deletion happened during complex history editing, reflog can recover commit pointers.

git reflog

Once you identify target reflog entry hash, you can inspect or restore file content from that point.

git show <reflog-hash>:path/to/file.txt

This is especially useful after accidental resets.

Team-Safe Workflow

In collaborative repositories:

1. restore on a dedicated branch
2. commit with clear recovery message
3. open pull request with context
4. avoid force pushes unless explicitly coordinated

This keeps blame history and incident response traceable.

Common Pitfalls

A common pitfall is restoring from deletion commit hash directly instead of its parent, which may not contain the file. Another is skipping content preview and restoring an unintended version. Teams also often rely on destructive history edits for simple file recovery and create unnecessary branch coordination issues. Finally, broad path restores can resurrect obsolete files unless reviewed carefully.

Summary

• Use git restore for precise file recovery workflows.
• Locate deletion commits with git log --diff-filter=D.
• Restore from deletion commit parent or any specific known-good commit.
• Commit recovery explicitly for safe collaboration.
• Validate recovered content before pushing to shared branches.