Unstaging Files

You ran git add on the wrong file, or staged changes you are not ready to commit, or realized you want to split your staged work into two separate commits. Unstaging lets you remove a file from the staging area without touching your working tree — the changes are preserved, just no longer queued for the next commit.

git restore —staged

git restore --staged pine-ridge.txt

The file is removed from the staging area. Your working-tree changes to the file are untouched. git status will now show the file under “Changes not staged for commit” instead of “Changes to be committed.”

To unstage everything at once:

git restore --staged .

What unstaging does not do

Unstaging does not:

• Delete your working-tree changes (your edits are still in the file)
• Revert the file to any previous version
• Touch any committed history

It only removes the file from the staging area. The change moves from “about to be committed” back to “modified but not yet staged.”

A common scenario: splitting a commit

You have been working and ran git add . without thinking. Now you have several files staged but you want to commit them separately — a bug fix in one commit, a new feature in another.

git status

Changes to be committed:
  modified:   index.html
  modified:   styles.css
  modified:   main.js

You want index.html and styles.css together (they are both part of the bug fix), but main.js belongs in a separate feature commit.

Unstage main.js:

git restore --staged main.js

Now commit the bug fix:

git commit -m "Fix hero image height on mobile"

Stage and commit the feature:

git add main.js
git commit -m "Add scroll-triggered card reveal"

The staging area is the tool that made this possible.

The old syntax: git reset HEAD

Before git restore --staged existed, the command was:

git reset HEAD pine-ridge.txt

HEAD is the current commit. This form of git reset is called a “mixed reset” scoped to a single file — it moves the file out of the staging area without touching the working tree. You will still see it in older documentation and Stack Overflow answers. Both work.

Comparing the two unstage forms

Command	Effect on working tree	Effect on staging area
git restore --staged <file>	None	Removed from staging
git reset HEAD <file>	None	Removed from staging

They produce the same result. git restore --staged is the recommended modern form.

Exercise

1. In your git-practice folder, make changes to two files — pine-ridge.txt and summit-challenge.txt.

2. Stage both:

git add .

3. Run git status to confirm both are staged.

4. Unstage summit-challenge.txt:

git restore --staged summit-challenge.txt

5. Run git status again. Confirm pine-ridge.txt is still staged and summit-challenge.txt is back in the unstaged section.

6. Open summit-challenge.txt and confirm your changes are still there — unstaging did not remove them.

7. Commit only the staged file:

git commit -m "Update Pine Ridge visit timing"

Then stage and commit summit-challenge.txt separately with a different message.

Recap

• git restore --staged <file> removes a file from the staging area without affecting working-tree changes.
• git restore --staged . unstages everything.
• Unstaging is not destructive — your edits are preserved in the working tree.
• Use unstaging to split staged changes into separate commits.
• The older equivalent is git reset HEAD <file>. Same behavior, still valid.

Next: amending the last commit — how to fix the commit message, add a forgotten file, or make small corrections immediately after committing.