HOWTO · Git

How to Undo rm in Git

Learn how to recover a file removed with git rm, whether the deletion is still staged or has been committed. Choose a safe Git command to restore the intended version from the index or a commit.

On this page

To undo git rm, first check whether the deletion is still staged or has been committed. Before a commit, restore the path from HEAD; after a commit, select a commit that contains the version you want and restore the path from it. Git can recover committed versions, but it cannot recreate file contents that were never committed.

Understanding what git rm changes

git rm <path> removes a tracked file from the working tree and stages its deletion in the index. The deletion is therefore ready to be included in the next commit. The command rm is not an alias for git remove; rm is a shell command, while git rm also updates Git’s index.

Use git rm --cached <path> when you want Git to stop tracking a file while keeping its working-tree copy. This stages removal from the index and leaves the file on disk. It is often used when a file should remain local but no longer belong in the repository.

Restore a deletion before committing

If the deletion is staged and you want the last committed version, restore the path from HEAD to both the index and working tree with git restore --source=HEAD --staged --worktree -- <path>. Check that your Git installation provides git restore before using it. If it does not, git checkout HEAD -- <path> restores that path from HEAD to the index and working tree.

These commands recover the committed version, not edits that existed only in the working tree. Inspect any staged or local changes for the path first, because restoring both locations replaces that path with the selected version. To restore several paths, list each path after --.

This self-contained example creates a temporary repository, commits a note, stages its removal, and restores the committed version. The final line is the restored file content.

set -eu
repo_dir="$(mktemp -d)"
trap 'rm -rf "$repo_dir"' EXIT
cd "$repo_dir"
git init -q
git config user.name "Example User"
git config user.email "example@example.invalid"
printf 'A tracked note.\n' > notes.txt
git add notes.txt
git commit -qm "Add note"
git rm -q notes.txt
if git restore --source=HEAD --staged --worktree -- notes.txt 2>/dev/null; then
  :
else
  git checkout HEAD -- notes.txt
fi
cat notes.txt

Expected stdout:

A tracked note.

Recover a deletion after committing

After a commit records the deletion, choose a commit that contains the desired file version. Then restore only that path with git restore --source=<commit> --staged --worktree -- <path>. If git restore is unavailable, use git checkout <commit> -- <path>. Replace <commit> and <path> with the selected commit and repository-relative path.

Restoring one path does not undo the commit that deleted it; it creates a staged file restoration that you can review and commit. Do not assume HEAD~1 is the right source: later commits may exist, and the immediately previous commit may not contain the version you need.

Find an earlier version with Git history

Use git log --all -- <path> to inspect commits that changed the path and identify one containing the desired version. git reflog records recent branch-tip positions and can help locate a commit after branch movement, such as a reset. It does not store separate file contents; the commit you select must contain the file version you want.

Once you identify a candidate, verify that it includes the path, then restore that path from the candidate commit using the command above. Git history only helps when the contents were committed. If the file was never committed, check editor backups, system backups, or other copies instead.

Choose a safe recovery method

Use the repository state to choose the source: restore from HEAD for an uncommitted staged deletion, or from a specific earlier commit for a committed deletion. Review the staged diff and working-tree status before committing the recovered file, especially if you have other work on the same path.

Avoid git reset --hard as a routine way to recover one file. It resets the index and working tree and can discard unrelated uncommitted changes. Restoring a single path from a chosen commit is more targeted. For multiple files, provide each path to the restore command and review the resulting changes before you commit.