Introduction

Running git rm -r . by mistake can look catastrophic because tracked files disappear from both working tree and index. The good news is that recovery is usually straightforward if you act before destructive follow-up commands. This guide explains safe recovery paths for uncommitted, staged, and committed cases.

Core Topic Sections

What git rm -r . actually changes

This command removes tracked files from the index and deletes them from working directory. It does not remove untracked files, and it does not erase commit history.

Because history still contains file snapshots, recovery is often possible.

First check status immediately:

git status

This tells you whether removal is staged, committed, or mixed with other changes.

Case 1: command run but not committed

If removal is staged but no commit happened, restore from HEAD.

git restore --staged .
git restore .

Equivalent older style:

git reset HEAD .
git checkout -- .

Use modern git restore when available because intent is clearer.

Case 2: removal committed locally

If you committed the deletion but did not push, reset to previous commit.

git log --oneline -n 3
git reset --hard HEAD~1

This rewinds branch to state before deletion commit. Be cautious if commit also contained unrelated work you still need.

If you want to keep commit history linear and avoid reset, use a reverting commit instead:

git revert <deletion-commit-sha>

Case 3: deletion commit already pushed

Avoid history rewrite on shared branches unless team policy allows it. Preferred recovery is a new revert commit.

git revert <deletion-commit-sha>
git push

This safely restores files while preserving shared commit history.

Recover specific files only

If you want only some files back:

git restore --source=HEAD -- path/to/file1 path/to/file2

From another commit:

git restore --source=<sha> -- path/to/file

Targeted restore reduces risk when repository has mixed intentional and accidental deletions.

Protect local uncommitted work before hard reset

If unrelated local changes exist, stash first.

1git stash push -m "temp before recovery"
2# recovery commands
3# optionally restore stash
4# git stash pop

This avoids losing valid in-progress changes during cleanup.

Verify integrity after recovery

After restoring, verify both filesystem and index state.

git status
git diff --name-status
git ls-files | head

If build system exists, run a quick compile or test step to confirm critical files are truly back.

Prevention techniques

To reduce accidental mass removals:

1. Use git status before running destructive commands.
2. Alias safer wrappers for remove operations.
3. Enable shell confirmation for risky aliases.
4. Use feature branches for high-risk file operations.

Small operational discipline prevents avoidable recovery incidents.

Recover when both deletion and edits exist

Sometimes you run git rm -r . after making valid local edits. In that case, recover deleted files first, then reapply intended edits from stash or patch files.

1git stash push -u -m "safety before restore"
2git restore --staged .
3git restore .
4git stash list
5git stash pop

After popping, resolve conflicts carefully. This sequence keeps accidental deletion recovery separate from real work, which lowers the chance of losing desired changes.

Common Pitfalls

• Running additional cleanup commands before checking repository status.
• Using reset --hard without stashing unrelated local work.
• Force-pushing rewritten history to shared branches without coordination.
• Assuming untracked files are recoverable through Git history.
• Restoring files in working tree but forgetting staged index state.

Summary

• git rm -r . removes tracked files but does not erase commit history.
• If uncommitted, use git restore to recover quickly.
• If committed and pushed, prefer git revert for safe shared recovery.
• Use targeted file restore when full rollback is unnecessary.
• Verify status and adopt preventive command discipline for future safety.