Unstage a file

Sometimes the index holds a file you do not want in the next commit. Maybe you ran git add . and swept in a file from a different change. Maybe you staged an experiment you are not ready to ship. Unstaging changes the index, not the working file. Your edits stay safe.

Inspect the current state first:

git status
git diff --staged -- README.md

git status lists the file under Changes to be committed. The staged diff shows exactly what would enter the commit. Notice that git status already prints the fix in its hint: use git restore —staged <file>… to unstage.

Unstage the file:

git restore --staged README.md

By default, Git restores the index entry from HEAD, the current commit. The staging area’s copy of README.md goes back to matching the last commit, as if you never ran git add. Your edited README.md stays in the working tree.

Verify both states:

git status
git diff -- README.md
git diff --staged -- README.md

The ordinary diff now shows the edit. The staged diff is empty. The file moved from Changes to be committed to Changes not staged for commit.

This is recoverable because the working content remains. It is different from git restore README.md, which targets the working tree and can overwrite unstaged content permanently. The --staged flag is the whole difference between a safe command and a destructive one.

Older tutorials use git reset HEAD README.md. Same effect. I prefer git restore --staged because the name says what it does.

Try this: stage two files, unstage one, and predict which file the next commit will contain. Run git commit, then check with git show --stat.