Introduction

Undoing git add means removing changes from the staging area without necessarily deleting the edits from your working tree. In other words, you want Git to forget that a file is prepared for the next commit, while keeping your local changes intact.

That is a staging problem, not a history rewrite problem. The correct commands operate on the index, not on existing commits.

What git add Actually Did

git add copies the current content of a file into the index, also called the staging area. The next commit is built from the index, not directly from the working tree.

So after this sequence:

git add app.js
git status

Git sees app.js as staged for commit.

If you change the file again after git add, those later edits are not automatically staged. That detail is important because “undoing git add” only removes the staged snapshot, not every later working-tree change.

Modern Command: git restore --staged

The clearest modern way to unstage a file is:

git restore --staged app.js

That restores the index entry for app.js from HEAD, which effectively undoes the git add for that file while leaving your working copy alone.

To unstage everything currently staged:

git restore --staged .

This is the command Git itself now suggests in many git status outputs.

Older and Still Valid: git reset

Older tutorials often use git reset for the same task:

git reset app.js

Or for all staged files:

git reset

This also unstages changes without deleting your working-tree edits. It is still valid and widely used, but git restore --staged is easier to read because it says exactly what you intend.

Partial Unstage With Patch Mode

Sometimes you do not want to unstage the whole file. You want to unstage only some hunks.

Use patch mode:

git restore --staged --patch app.js

Git will interactively ask which staged hunks to remove from the index. This is useful when you accidentally staged too much and want to keep only part of the file in the next commit.

Unstage Versus Discard

Unstaging is not the same as discarding local edits.

If you run:

git restore --staged app.js

your file still contains your changes in the working tree.

If you also want to throw away those working-tree edits, that is a different operation:

git restore app.js

That command can destroy local work, so do not mix it up with unstaging.

A Small Example Workflow

1echo "debug" >> app.js
2git add app.js
3git status
4
5git restore --staged app.js
6git status

After the first status, the file appears under “Changes to be committed.” After git restore --staged, it moves back to “Changes not staged for commit.”

That is exactly what you usually want when you staged something too early.

When a New File Is Involved

For a newly created file, unstaging removes it from the index but does not delete the file from disk.

So if you accidentally staged a new file:

git restore --staged newfile.txt

the file remains in your working directory as an untracked file.

That behavior is often surprising the first time, but it is consistent: unstaging affects the index, not the filesystem contents.

Common Pitfalls

A common mistake is using a destructive checkout or restore command when you only meant to unstage. git restore and git restore --staged do different things.

Another mistake is thinking git add creates a permanent history change. It does not. Until you commit, you are only editing the index.

People also forget that staging is snapshot-based. If you edit a file after staging it, the working tree and index may now differ.

Finally, do not use history-rewriting commands to solve a pre-commit staging issue. If no commit exists yet, there is nothing in history to rewrite.

Summary

• Undoing git add means removing a file from the staging area, not deleting your edits.
• The clearest modern command is git restore --staged <file>.
• 'git reset <file> also works and is still common in older workflows.'
• Use patch mode if only part of the staged file should be unstaged.
• Be careful not to confuse unstaging with discarding working-tree changes.