How to Undo Git Add Before Commit

Running git add puts changes into Git's staging area, also called the index, so they can be included in the next commit. If you added the wrong file or staged more than you intended, you can undo that staging step without deleting your working files or edits.

Review what is staged

Before changing the index, check the repository status and inspect the staged diff:

git status
git diff --staged

git status separates staged changes from unstaged changes. git diff --staged shows the patch that would be included in the next commit, so review it before committing.

Unstage one file

Use git restore --staged to remove a path from the next commit while leaving the working-tree file and its contents in place:

git restore --staged -- app.py
git status

The file's staged version is reset to the current commit, while your working-tree edits remain available to edit or stage again. If the file is newly created and has never been committed, it becomes untracked rather than being deleted.

Unstage all files or several selected files

To unstage everything under the current directory, run the command from the repository root:

git restore --staged -- .

To unstage only selected paths, list them after --:

git restore --staged -- app.py config.js README.md

Check git status afterward. Paths are interpreted relative to your current directory unless you use an explicit pathspec, so running the all-files command from a subdirectory may affect only that part of the repository.

Unstage selected hunks

If only part of a file should be removed from staging, use interactive patch mode:

git restore --staged --patch -- app.py

Git presents staged changes in sections so you can choose which hunks to unstage. Review the result with git diff --staged and git diff before committing.

Use the traditional git reset form

Older workflows commonly use git reset with a path to unstage changes while keeping the working tree intact:

git reset HEAD -- app.py

# Unstage all paths from the repository root
git reset HEAD -- .

When a path is specified, this updates the index from HEAD; it does not move the current branch. For new work, git restore --staged makes the intent clearer.

Accidentally staged a secret or generated file?

Unstage it before committing, then add an appropriate ignore rule if it should stay out of future commits:

git restore --staged -- .env

# Add this pattern to .gitignore
.env

git status

Adding a path to .gitignore does not automatically remove it from the index; unstage it first and verify the status. If a secret was already committed or pushed, unstaging is not enough: rotate or revoke the credential, then follow your team's process for removing sensitive data from history.

Unstaging is not deleting

These commands change what is staged for the next commit. They do not delete the file from your working directory or discard its edits. By contrast, git reset --hard can discard staged and unstaged changes to tracked files, so do not use it just to undo git add.

Quick reference

• Unstage one file: git restore --staged -- file.txt.
• Unstage all paths from the repository root: git restore --staged -- ..
• Unstage selected files: git restore --staged -- file1 file2.
• Unstage selected hunks: git restore --staged --patch -- file.txt.
• Traditional alternative: git reset HEAD -- file.txt.
• Review staged content: git diff --staged.