Undo git add without discarding your changes

Use git restore --staged -- path to undo staging while preserving the working-tree file. In a repository with an existing commit, it resets the selected index entry to HEAD without copying that old version over your local edits.

git restore --staged -- src/app.js
git restore --staged -- src/

git restore was introduced in Git 2.23. The older path-based equivalent is git reset HEAD -- src/app.js.

Unstage the intended scope

# Current directory and descendants
git restore --staged -- .

# All paths, even when called from a subdirectory
git restore --staged -- :/

# Reset the whole index to HEAD, preserving the working tree
git reset

A plain git restore -- path has a different effect: it replaces working-tree contents from the index and discards unstaged edits in that path. Keep --staged when the goal is only to change what the next commit will include.

Newly added files

If a file is staged but does not exist in HEAD, unstaging removes its index entry and leaves the disk file untracked, or ignored if an ignore rule matches it.

Before the repository's first commit, there is no HEAD tree for the normal restore command to read. Remove a newly staged path from the index instead:

git rm --cached -- new-file.txt

The working-tree copy remains. If its staged contents differ from the current file, inspect both before overriding any safety check.

Unstage selected hunks

git restore --staged --patch -- src/app.js
# Older alternative:
git reset -p -- src/app.js

Review the remaining staged patch with git diff --cached, then check the working-tree changes with git diff. Patch mode changes the staging boundary rather than deleting your file edits.

FAQ

What if I already committed the wrong file?

For a local, unshared commit with a parent, git reset --soft HEAD^ moves the branch back while retaining the index. You can then unstage the unwanted path and recommit the reviewed remainder. Save unrelated work first. Shared history normally needs a corrective commit rather than a casual rewrite.

Does unstaging a tracked file stop tracking it permanently?

No. It restores that path's index state from HEAD. If the file is in the current commit, it remains tracked. Permanently removing it from future commits is a different git rm --cached workflow.

How do I confirm that nothing was lost?

Inspect the file contents and compare git diff with git diff --cached. Unstaging changes which version is queued for the next commit; the working-tree file is left alone.

See git-restore, git-reset, and git-rm.