How do I undo 'git add' before commit?

Undo git add for uncommitted changes with:

git reset <file>

That will remove the file from the current index (the "about to be committed" list) without changing anything else.

To unstage all changes for all files:

git reset

In old versions of Git, the above commands are equivalent to git reset HEAD <file> and git reset HEAD respectively, and will fail if HEAD is undefined (because you haven't yet made any commits in your repository) or ambiguous (because you created a branch called HEAD, which is a stupid thing that you shouldn't do). This was changed in Git 1.8.2, though, so in modern versions of Git you can use the commands above even prior to making your first commit:

"git reset" (without options or parameters) used to error out when you do not have any commits in your history, but it now gives you an empty index (to match non-existent commit you are not even on).

Documentation: git reset

You want:

git rm --cached <added_file_to_undo>

Reasoning:

When I was new to this, I first tried

git reset .

(to undo my entire initial add), only to get this (not so) helpful message:

fatal: Failed to resolve 'HEAD' as a valid ref.

It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like:

1. cd to my great new project directory to try out Git, the new hotness
2. git init
3. git add .

4. git status

   ... lots of crap scrolls by ...

   => Damn, I didn't want to add all of that.

5. google "undo git add"

   => find Stack Overflow - yay

6. git reset .

   => fatal: Failed to resolve 'HEAD' as a valid ref.

It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.

And that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap)

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

And the solution indeed is to use git rm --cached FILE.

Note the warnings elsewhere here - git rm deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm:

--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.

I proceed to use

git rm --cached .

to remove everything and start again. Didn't work though, because while add . is recursive, turns out rm needs -r to recurse. Sigh.

git rm -r --cached .

Okay, now I'm back to where I started. Next time I'm going to use -n to do a dry run and see what will be added:

git add -n .

I zipped up everything to a safe place before trusting git help rm about the --cached not destroying anything (and what if I misspelled it).

If you type:

git status

Git will tell you what is staged, etc., including instructions on how to unstage:

use "git reset HEAD <file>..." to unstage

I find Git does a pretty good job of nudging me to do the right thing in situations like this.

Note: Recent Git versions (1.8.4.x) have changed this message:

(use "git rm --cached <file>..." to unstage)

2019 update

As pointed out by others in related questions (see here, here, here, here, here, here, and here), you can now unstage a single file with:

git restore --staged <file>

and unstage all files (from the root of the repo) with:

git restore --staged .

Notes

git restore was introduced in July 2019 and released in version 2.23.
With the --staged flag, it restores the content of the index (what is asked here).

When running git status with staged uncommitted file(s), this is now what Git suggests to use to unstage file(s) (instead of git reset HEAD <file> as it used to prior to v2.23).

To remove new files from the staging area (and only in case of a new file), as suggested above:

git rm --cached FILE

Use rm --cached only for new files accidentally added.

Suppose I create a new file, newFile.txt:

Suppose I add the file accidentally, git add newFile.txt:

Now I want to undo this add, before commit, git reset newFile.txt:

For a specific file:

• git reset my_file.txt
• git checkout my_file.txt

For all added files:

• git reset .
• git checkout .

Note: checkout changes the code in the files and moves to the last updated (committed) state. reset doesn't change the codes; it just resets the header.

To undo git add, use:

git reset filename

git reset filename.txt  

Will remove a file named filename.txt from the current index, the "about to be committed" area, without changing anything else.

You can unstage/undo using the git command or GUI git.

Single file

git reset File.txt 

Multiple files

git reset File1.txt File2.txt File3.txt

Example - Suppose you have added Home.js, ListItem.js, Update.js by mistake and want to undo/reset =>

git reset src/components/home/Home.js src/components/listItem/ListItem.js src/components/update/Update.js

Same Example using git GUI

git gui

opens a window => Uncheck your files from Staged changes(Will Commit)

If you want to revert the last commit but still want to keep the changes locally that were made in the commit, use this command:

git reset HEAD~1 --mixed

The git reset command helps you to modify either the staging area or the staging area and working tree. Git's ability to craft commits exactly like you want means that you sometimes need to undo changes to the changes you staged with git add.

You can do that by calling git reset HEAD <file to change>. You have two options to get rid of changes completely. git checkout HEAD <file(s) or path(s)> is a quick way to undo changes to your staging area and working tree.

Be careful with this command, however, because it removes all changes to your working tree. Git doesn't know about those changes since they've never been committed. There's no way to get those changes back once you run this command.

Another command at your disposal is git reset --hard. It is equally destructive to your working tree - any uncommitted changes or staged changes are lost after running it. Running git reset -hard HEAD does the same thing as git checkout HEAD. It just does not require a file or path to work.

You can use --soft with git reset. It resets the repository to the commit you specify and stages all of those changes. Any changes you have already staged are not affected, nor are the changes in your working tree.

Finally, you can use --mixed to reset the working tree without staging any changes. This also unstages any changes that are staged.

You can using this command after git version 2.23 :

git restore --staged <filename>

Or, you can using this command:

git reset HEAD <filename>

I would use git restore --staged . or git restore --staged <filename>

You can also use git rm --cached, however, the git rm command should be ideally used for already tracked files.

The first time I had this problem, I found this post here and from the first answer I learned that I should just do git reset <filename>. It worked fine.

Eventually, I happened to have a few subfolders inside my main git folder. I found it easy to just do git add . to add all files inside the subfolders and then git reset the few files that I did not want to add.

Nowadays I have lots of files and subfolders. It is tedious to git reset one-by-one but still easier to just git add . first, then reset the few heavy/unwanted but useful files and folders.

I've found the following method (which is not recorded here or here) relatively easy. I hope it will be helpful:

Let's say that you have the following situation:

Folder/SubFolder1/file1.txt
Folder/SubFolder2/fig1.png
Folder/SubFolderX/fig.svg
Folder/SubFolder3/<manyfiles>
Folder/SubFolder4/<file1.py, file2.py, ..., file60.py, ...>

You want to add all folders and files but not fig1.png, and not SubFolderX, and not file60.py and the list keeps growing ...

First, make/create a bash shell script and give it a name. Say, git_add.sh:

Then add all the paths to all folders and files you want to git reset preceded by git reset -- . You can easily copy-paste the paths into the script git_add.sh as your list of files grows. The git_add.sh script should look like this:

#!/bin/bash

git add .
git reset -- Folder/SubFolder2/fig1.png
git reset -- Folder/SubFolderX
git reset -- Folder/SubFolder4/file60.py

#!/bin/bash is important. Then do source git_add.sh to run it. After that, you can do git commit -m "some comment", and then git push -u origin master if you have already set up Bitbucket/Github.

Disclaimer: I've only tested this in Linux.

If you have lots of files and folders that you always retain in your local git repository but you don't want git to track changes when you do git add ., say video and data files, you must learn how to use .gitignore. Maybe from here.

git add -A

is used to add all files to your commit (stage).

git reset

is the opposite of 'git add -A' command. It removes all the files that are staged(means ready) to be committed.

Likewise, to add a specific file to commit we use git add <filename> Same way, to unstage(or reset) a specific file that we added using git add we use git reset <filename> .

git reset is the exact opposite of git add.