Introduction

When Git says a deleted file is staged, it means the index now records that deletion for the next commit. Fixing it is easier once you separate two different questions: do you want to remove the deletion from the staging area, and do you also want the file restored in the working tree.

Core Sections

Understand the three Git states involved

Git behavior makes more sense if you think in terms of three snapshots:

• 'HEAD, which is the last committed version'
• the index, which is the staged snapshot for the next commit
• the working tree, which is what exists on disk right now

Suppose notes.txt exists in HEAD. You delete it locally and then stage everything.

rm notes.txt
git add -A
git status

At this point, the working tree no longer has the file, and the index records a staged deletion. The next commit will remove the file unless you change the index state.

Unstage the deletion but keep the local file deleted

If you only want to remove the deletion from the next commit, use git restore --staged.

git restore --staged notes.txt

After this command, Git stops staging the deletion, but the file is still missing from your working tree. git status will typically show it as a deleted but unstaged change.

This is the right move when you are not sure yet whether the file should be removed and you simply want it out of the current commit.

Restore the file as well

If deleting the file was a mistake, you need a second step to bring it back onto disk.

git restore --staged notes.txt
git restore notes.txt

The first command fixes the index. The second command restores the working tree copy from HEAD.

Keeping those steps separate is useful because it matches how Git models the repository: one command changes the staged snapshot, and the other changes the on-disk file.

Older Git versions use different commands

git restore is the modern syntax, but older Git versions may not support it. In that case, the equivalent unstaging command is:

git reset HEAD notes.txt

And if you also want the file back in the working tree, the older restore syntax is:

git checkout -- notes.txt

The newer commands are preferred because they make the target clearer: are you restoring the index, the working tree, or both.

Read git status after each step

git status is the fastest way to confirm whether you changed the right state.

Typical progression:

1. After deletion and staging, the file appears as deleted in the staged section.
2. After git restore --staged, it appears as deleted in the unstaged section.
3. After git restore, it disappears from the change list completely.

That progression is a good sanity check when you are learning the commands.

Why this mistake happens so often

Developers usually hit this case after broad staging commands such as git add -A, git add ., or an IDE action that stages every change. Accidental deletions are common when cleaning up generated files, renaming directories, or moving paths around during refactors.

Knowing how to unstage a deleted file cleanly helps keep commits focused. It lets you separate "I changed my working tree" from "I intend to commit that specific deletion."

Common Pitfalls

• Expecting git restore --staged file to recreate the file on disk misunderstands the difference between the index and the working tree.
• Using a broad reset command to fix one file can disturb unrelated staged changes.
• Restoring the file immediately without checking status can hide the fact that the real issue was an accidentally staged deletion.
• Confusing git rm --cached with unstaging a deleted tracked file leads to the wrong fix for the problem at hand.
• Forgetting that older Git versions may need git reset HEAD file instead of git restore --staged file can make advice seem inconsistent across machines.

Summary

• A staged deletion lives in the Git index, not only in the working tree.
• Use git restore --staged file to remove the deletion from the next commit.
• Use git restore file as a separate step if you also want the file back on disk.
• Older Git installations can use git reset HEAD file and git checkout -- file for the same workflow.
• Thinking in terms of HEAD, index, and working tree makes this kind of Git cleanup much easier.