Unstaging a file means telling Git to stop preparing it for the next commit

When you run git add, you tell Git to stage a file — to mark it as ready to include in your next commit. If you stage a file by mistake, or change your mind about including it, you can unstage it with git reset HEAD followed by the filename. The file stays in your working directory with all your changes intact; you are only removing it from the staging area.

The command works the same way whether you staged one file or many. Git will not delete your work or undo your edits — it only removes the file from the list of things about to be committed.

Key Takeaways

  • Use git reset HEAD filename to unstage a single file while keeping your changes.
  • Use git reset HEAD with no filename to unstage all files at once.
  • Unstaging does not delete your work or undo edits — the file remains in your working directory unchanged.
  • In Git 2.23 and later, you can also use git restore --staged filename as an alternative command.

The basic unstage command for a single file

To unstage one file, type git reset HEAD followed by the filename:

git reset HEAD config.json

Git will respond with something like "Unstaged changes after reset" and show you the filename. The file is now out of the staging area. If you run git status, it will appear under "Changes not staged for commit" instead of "Changes to be committed".

The filename can be a full path if the file is in a subdirectory. For example: git reset HEAD src/components/Button.js. You can also use wildcards to unstage groups of files with similar names, such as git reset HEAD *.css to unstage all CSS files at once.

Unstaging multiple files or everything at once

If you staged several files and want to unstage all of them, use git reset HEAD with no filename:

git reset HEAD

This removes every file from the staging area in one command. Your changes remain in your working directory; nothing is lost. This is useful when you have run git add . to stage everything and then realized you want to be more selective about what goes into the next commit.

You can also unstage specific files one at a time by running the single-file command multiple times, or you can list multiple filenames in one command: git reset HEAD file1.js file2.js file3.js. This approach gives you more control when you only want to remove certain files from the staging area.

Using git restore as an alternative in newer Git versions

Git 2.23 (released in August 2019) introduced git restore as a newer way to handle unstaging. If your Git version is 2.23 or later, you can use:

git restore --staged filename

This does exactly the same thing as git reset HEAD — it unstages the file without changing your work. The --staged flag is what tells Git to remove it from the staging area specifically.

Both commands work identically. Use whichever one feels more natural to you, or whichever one your team prefers. If you are working on a project with older Git versions, stick with git reset HEAD since git restore may not be available. Many developers still use git reset HEAD out of habit even on newer versions.

What happens to your changes when you unstage

Unstaging a file does not touch your edits. The changes you made to the file stay exactly as they are in your working directory. You are only changing Git's internal record of what is ready to commit.

If you want to undo your actual edits to a file (not just unstage it), that is a different operation. You would use git checkout HEAD filename or git restore filename to revert the file to its last committed state. But unstaging alone leaves your work untouched. This distinction matters because unstaging is reversible — you can always stage the file again — while reverting changes is permanent unless you use Git's reflog.

Checking what is staged before you commit

Before you commit, run git status to see what is staged and what is not. Files under "Changes to be committed" will go into your next commit. Files under "Changes not staged for commit" will not.

You can also use git diff --staged to see the exact changes in every staged file. This is useful if you want to review what you are about to commit before you actually commit it. Running this command before every commit helps catch mistakes and keeps your commit history clean and organized.

Frequently Asked Questions

Does unstaging delete my changes?

No. Unstaging only removes the file from the staging area. Your edits remain in the working directory exactly as they are. If you want to undo your changes, you need to use a different command like git restore filename or git checkout HEAD filename.

Can I unstage a file that I have already committed?

No. Once a file is committed, it is part of your repository history. Unstaging only works on files in the staging area. If you want to change a file that is already committed, you would use git revert or git reset to undo the commit itself, which is a different process.

What is the difference between git reset HEAD and git restore --staged?

They do the same thing: both unstage a file. git restore --staged is the newer command (Git 2.23+) and is considered more intuitive. git reset HEAD is older and works on all Git versions. Use whichever your team uses or whichever you prefer.

Can I unstage just part of a file?

Yes, with git reset --patch or git restore --staged --patch. Git will walk you through each change in the file and ask whether you want to unstage it. This is useful if you staged a file with multiple edits but only want to commit some of them.

What if I unstage a file by accident?

You can stage it again with git add filename. Unstaging is not permanent — it only changes what Git is preparing for the next commit. Your changes are still there, and you can always stage the file again if you change your mind.