Git Undo Add: Unstage Files After git add

Undoing git add means reversing a staging mistake — you staged a path you did not mean to include in the next commit. Your edits stay on disk; Git resets the index entry for that path toward HEAD. If you need a full guide to every unstage command (git rm --cached, folders, and comparisons), see Git unstage files.

Four situations this article covers:

• read git status -sb to see what is staged;
• unstage one file you added by mistake;
• undo git add . for every staged path;
• unstage a deletion you staged with git add or git rm.

Pick your status line in the table below, then jump to that section. These commands apply only before git commit; committed work needs Git reset examples or revert to previous commit.

Choose the Right Unstage Command

No commits yet? git restore --staged needs HEAD. In a newly initialized repository before the first commit, use git reset <path> instead.

These unstage commands do not delete untracked files from disk.

Read git status -sb First

Scenario: you ran git add and want to confirm what is staged before you unstage.

Short status shows the branch on the first line, then one row per changed path. Read the two change columns from left to right:

git status -sb

## main
M  app.txt
 M notes.txt

The first column is the staging area; the second is the working tree. In the sample output, M app.txt has M in the first column, so that change is staged. M notes.txt has M in the second column only, so the file is modified in the working tree but not staged.

Unstage One File

Scenario: you staged app.txt but meant to leave it out of the next commit.

With app.txt staged and notes.txt only modified on disk, status looks like the block above. Remove app.txt from the staging area:

git restore --staged app.txt

Check that only the working-tree column still shows app.txt:

git status -sb

## main
 M app.txt
 M notes.txt

Both files still have your edits — app.txt is simply unstaged again. Nothing was deleted from disk.

In a brand-new repository with no commit yet, git restore --staged may fail with fatal: could not resolve HEAD because it restores the index from HEAD. Use git reset file instead — see Troubleshooting.

Undo git add .

Scenario: you ran git add . and want every path out of the staging area at once.

Assume both files were staged:

git status -sb

## main
M  app.txt
M  notes.txt

Unstage paths under the current directory — . means this directory and everything below it. Run it from the repository root if you intend to unstage changes across the whole repo:

git restore --staged .

Confirm both files show a space in the first column:

git status -sb

## main
 M app.txt
 M notes.txt

Bare git reset also unstages changes while keeping working-tree edits, but it applies to the repository's staged changes rather than being limited by the . pathspec. When the goal is specifically to undo git add ., run git restore --staged . from the repository root.

Unstage With git reset HEAD

Scenario: you follow a script or tutorial that uses git reset HEAD to undo git add.

After staging app.txt:

git reset HEAD app.txt

Unstaged changes after reset:
M	app.txt
M	notes.txt

Short status confirms app.txt is unstaged:

git status -sb

## main
 M app.txt
 M notes.txt

This is the traditional alternative to git restore --staged. On modern Git, both achieve the same unstage result for a single file — see Git restore examples for restore-focused workflows.

Unstage a Staged Deletion

Scenario: you deleted a tracked file and staged that removal, but you want the delete out of the index before commit.

After rm tracked.txt and git add tracked.txt, status shows a staged deletion:

git status -sb

## main
 M app.txt
 M notes.txt
D  tracked.txt

D in the first column means the deletion is staged. Unstage it:

git restore --staged tracked.txt

The deletion moves out of the staging area — the file is still missing on disk until you restore it:

git status -sb

## main
 M app.txt
 M notes.txt
 D tracked.txt

D tracked.txt means unstaged deletion. To bring the file back from the last commit, run git restore tracked.txt — that is a separate step from undoing git add.

git rm --cached Is Not Undo Add

Unstaging reverses git add when you still want the file tracked. If you only staged a file by mistake, use git restore --staged file. Use git rm --cached when the goal is to stop tracking the path while keeping it on disk — see remove file from tracking and gitignore examples.

After git commit

Once you run git commit, the snapshot is in history. After the commit is created, those changes are no longer in the staging-area state you are trying to undo — you now need to undo or change the commit instead. Use Git reset examples or revert to previous commit.

Troubleshooting

References

• git-restore documentation
• git-reset documentation
• git-status documentation

Summary

Undoing git add removes paths from the staging area and leaves your edits on disk. git status -sb shows what is staged — look for M or D in the first column. Use git restore --staged file for one path, or git restore --staged . from the repo root to reverse git add ..

Before the first commit, use git reset file if git restore --staged cannot resolve HEAD. Bare git reset unstages the whole repository; git reset HEAD file is also valid on repos with history. Staged deletions use the same unstage command — then git restore file if you need the file back from HEAD.

This page targets undo git add mistakes before commit. For broader unstage command coverage — git rm --cached, directories, and side-by-side comparisons — see Git unstage files. To discard edits or undo commits, see Git discard changes and Git reset examples.