Chapter 2.6 — Recover Deleted Files☕ 14 min read

Recover Deleted Files

Tracked file hai toh git restore se wapas lao. Committed delete hai toh purane commit se recovery karo. Untracked file? Woh gayi bhai, wapas nahi aayegi.

01Three Deletion Scenarios

File delete ho gayi? Calm down. Before you panic, figure out how the file was deleted. The recovery method depends entirely on the deletion state.

Three common deletion scenarios:

Scenario 1: You used rm app.js (OS delete) on a tracked file, but have not committed the deletion yet.
Scenario 2: You used git rm app.js (Git delete), which stages the deletion. Maybe you even committed it.
Scenario 3: You deleted a file many commits ago and just realized you need it back.

The recovery method depends on whether the deletion was committed and whether it was staged. Different states require different commands.

The golden rule: Git stores every version of every file that was ever committed. Uncommitted changes are at risk — but committed files can almost always be recovered.

git status is your first diagnostic tool — it tells you what Git sees right now.

# Accidental deletion scenarios
rm important.txt           # OS delete (untracked or modified)
git rm important.txt       # Git delete (stages the deletion)
git rm --cached secret.txt # Untrack but keep local file

# Check what happened
git status
# deleted: important.txt  (if tracked)
# Untracked: important.txt (if untracked and OS-deleted, it just vanishes)

First step always: Run git status before doing anything else. It tells you whether the deletion is staged, unstaged, or committed. Your recovery strategy depends on this information. Acting without checking can make things worse.

02Uncommitted Deletion — git restore

If you deleted a file but have not committed the deletion, recovery is straightforward. The file content still exists in the last commit (HEAD).

Scenario 1: OS delete (rm), not yet staged

You used rm app.js on a tracked file. The file is gone from your working directory, but Git still has the last committed version. Simply run git restore app.js to bring it back.

Scenario 2: Git delete (git rm), staged but not committed

git rm does two things: deletes the file from your working directory AND stages the deletion. You need to undo both steps. First, unstage with git restore --staged app.js. Then restore the file with git restore app.js.

Scenario 3: Modified, then OS deleted

If you modified a file and then deleted it with rm, git restore will bring back the last committed version — your uncommitted modifications are lost.

git restore restores from the last committed version (HEAD). It does not recover uncommitted changes.

git restore --staged unstages a change, moving it back to the working directory state. It does not restore file content.

# Scenario 1: OS delete (rm), not yet staged
rm app.js
git status
# deleted: app.js
git restore app.js
# File is back!

# Scenario 2: git rm (staged), not yet committed
git rm app.js
git status
# deleted: app.js (staged)
git restore --staged app.js  # unstage the deletion
git restore app.js           # restore the file content
# File is back!

# Scenario 3: Modified, then OS deleted
echo "new changes" >> app.js
rm app.js
git restore app.js
# WARNING: Your "new changes" are lost!
# git restore reverts to the last COMMITTED version.

Warning: git restore reverts to the committed state, not the last saved state. If you modified a file and then deleted it, git restore brings back the committed version — your uncommitted changes are permanently lost. This is why committing or stashing frequently is crucial.

03Committed Deletion — Restore from Old Commit

If the deletion was committed, you need to find the last commit where the file existed. Then restore the file from that specific commit.

Step 1: Find the commit

git log -- important.txt shows commits that touched this file. The commit before the deletion is the one you want.

git rev-list -n 1 HEAD -- important.txt gives you the LAST commit hash where this file existed. Quick and precise.

Step 2: Restore the file

git restore -s def5678 important.txt restores the file from that specific commit into your working directory. The -s flag means "source" — which commit to restore from.

Alternative: git checkout def5678 -- important.txt (older syntax, still works).

Step 3: Commit the recovery

After restoring, the file is in your working directory but NOT committed. You must git add and git commit to bring it back into the repository history permanently.

# The file was deleted in a commit
git log --oneline -- important.txt
# abc1234 remove important file
# def5678 add important file

# Find the commit BEFORE the deletion
# Option 1: Use the commit hash where it existed
git restore -s def5678 important.txt

# Option 2: Use HEAD~1 (if the delete was the last commit)
git restore -s HEAD~1 important.txt

# The file is now back in your working directory (unstaged)
git add important.txt
git commit -m "chore: recover important.txt"

# Alternative older syntax (still works)
git checkout def5678 -- important.txt

Always commit after recovery! git restore -s only puts the file in your working directory. Until you git add and git commit, Git does not consider it part of the branch. If you switch branches or run git clean, the recovered file could be lost again.

04Finding Deep History — Search Across Branches

If a file was deleted many commits ago, finding the right commit hash can be tricky. But Git has powerful search tools.

git log --all --full-history -- important.txt searches ALL branches for the file history. This finds the file even if it was deleted on a different branch.

git rev-list --all -- important.txt lists all commits that touched the file, across all branches.

Once you find the commit hash where the file existed, restore with git restore -s hash important.txt.

If the file path changed — it was in a different directory — use the old path in your search. Git matches by path, not by filename alone.

git show hash:important.txt displays the file content from that commit. You can redirect it to save manually: git show hash:important.txt > important_recovered.txt

# Find when the file existed across all branches
git log --all --full-history -- important.txt

# If you know part of the file name but not the path
git log --all --full-history -- "**/important*"

# Once you find the commit (e.g., def5678)
git restore -s def5678 important.txt
git add important.txt
git commit -m "chore: recover important.txt from def5678"

# Alternative: Save content to a new file manually
git show def5678:important.txt > important_recovered.txt
# Useful if you want to review before restoring to the original path

Pro Tip: git show hash:path lets you preview a file from any commit without restoring it. Use this to verify you found the right version before running git restore. This is especially useful when the file was deleted long ago and you want to confirm the content first.

05Prevention — Protect Your Files

Recovery is great, but prevention is better. Here are strategies to protect your important files.

Untracked files deleted with rm cannot be recovered by Git. Only committed files are safe. This is the single most important thing to remember.

Commit often, especially for important changes. A WIP commit is infinitely better than lost work. You can always amend or squash later.

Stash before risky operations. git stash push -m "WIP: important changes" saves your work safely. After the risky operation, git stash pop brings it back.

Use .gitignore to prevent accidental commits of sensitive files. But remember, .gitignore does not protect from rm — it only prevents Git from tracking.

Pre-commit hooks can prevent deletion of critical files. Add a hook that blocks commits deleting protected files like config.yml or .env.production.

For local development, use an editor or IDE with local history (VS Code, IntelliJ). These track changes independently of Git.

# Prevention 1: Commit often
git add -A && git commit -m "WIP: important feature in progress"

# Prevention 2: Stash before risky operations
git stash push -m "WIP: important changes"
# Now your working directory is clean
git stash pop  # bring changes back

# Prevention 3: Pre-commit hook to block deletion of critical files
# .git/hooks/pre-commit
# CRITICAL_FILES="config.yml .env.production"
# for file in $CRITICAL_FILES; do
#   if git diff --cached --name-only | grep -q "$file"; then
#     if git diff --cached --diff-filter=D --name-only | grep -q "$file"; then
#       echo "BLOCKED: Cannot delete $file"
#       exit 1
#     fi
#   fi
# done

The best recovery is prevention. Commit your work regularly. Stash before risky operations. Use pre-commit hooks to protect critical files. Git is a safety net, but only for files it knows about. Untracked files that are deleted are gone forever — no command can bring them back.

Lo kar liya — Key Points:

✅ If you used OS rm on a tracked file, recover with git restore file — restores from the last commit
✅ If you used git rm (staged), unstage with git restore --staged file, then restore with git restore file
✅ If the deletion was committed, find the last commit where the file existed using git log -- file
✅ Restore from a specific commit with git restore -s commit file or git checkout commit -- file
✅ Untracked files deleted with rm are GONE FOREVER — Git has no record of them
✅ For files deleted long ago, use git log --all --full-history -- file to search across all branches

Previous2.5 — Undo Old Commits — revert vs reset 📋 All Chapters Next Chapter2.7 — Stash Pop Conflict →