如何从 Git 中的暂存区（= 索引 = 缓存）中删除文件？

Question

EDIT This question can be understood in two ways, and the optimal answer is different in the two cases.

• Question 1: I added a previously untracked file to the staging area. How can I remove this file from the staging area without removing it from the file system?

  Answer 1: Use the following command, as described in John Feminella's answer :

   git rm --cached <file>

• Question 2: I modified a file already tracked , and added my modifications to the staging area. How can I remove my modifications from the staging area? Ie, how can I unstage my modifications in the file?

  Answer 2: Use the following command, as described in David Underhill's answer :

   git reset <file>

Answer 1

You want:

git rm --cached [file]

If you omit the --cached option, it will also delete it from the working tree. git rm is slightly safer than git reset , because you'll be warned if the staged content doesn't match either the tip of the branch or the file on disk. (If it doesn't, you have to add --force .)

Answer 2

这应该为您取消暂存 <file> （无需删除或以其他方式修改文件）：

git reset <file>

Answer 3

git reset HEAD <file> 

for removing a particular file from the index.

and

git reset HEAD

for removing all indexed files.

Answer 4

Depending on your workflow, this may be the kind of thing that you need rarely enough that there's little point in trying to figure out a command-line solution (unless you happen to be working without a graphical interface for some reason).

Just use one of the GUI-based tools that support index management, for example:

• git gui <-- uses the Tk windowing framework -- similar style to gitk
• git cola <-- a more modern-style GUI interface

These let you move files in and out of the index by point-and-click. They even have support for selecting and moving portions of a file (individual changes) to and from the index.

---

How about a different perspective: If you mess up while using one of the suggested, rather cryptic, commands:

• git rm --cached [file]
• git reset HEAD <file>

...you stand a real chance of losing data -- or at least making it hard to find. Unless you really need to do this with very high frequency, using a GUI tool is likely to be safer .

---

Working without the index

Based on the comments and votes, I've come to realize that a lot of people use the index all the time. I don't. Here's how:

• Commit my entire working copy (the typical case): git commit -a
• Commit just a few files: git commit (list of files)
• Commit all but a few modified files: git commit -a then amend via git gui
• Graphically review all changes to working copy: git difftool --dir-diff --tool=meld

Answer 5

Only use git rm --cached [file] to remove a file from the index.

git reset <filename> can be used to remove added files from the index given the files are never committed .

% git add First.txt
% git ls-files
First.txt
% git commit -m "First"   
% git ls-files            
First.txt
% git reset First.txt
% git ls-files              
First.txt

NOTE: git reset First.txt has no effect on index after the commit.

Which brings me to the topic of git restore --staged <file> . It can be used to (presumably after the first commit) remove added files from the index given the files are never committed .

% git add Second.txt              
% git status        
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   Second.txt
% git ls-files       
First.txt
Second.txt
% git restore --staged Second.txt
% git ls-files 
First.txt
% git add Second.txt 
% git commit -m "Second"
% git status            
On branch master
nothing to commit, working tree clean
% git ls-files 
First.txt         
Second.txt
Desktop/Test% git restore --staged .
Desktop/Test% git ls-files
First.txt                   
Second.txt
Desktop/Test% git reset .                    
Desktop/Test% git ls-files
First.txt
Second.txt
% git rm --cached -r .
rm 'First.txt'
rm 'Second.txt'
% git ls-files  

tl;dr Look at last 15 lines. If you don't want to be confused with first commit, second commit, before commit, after commit.... always use git rm --cached [file]

Answer 6

According to my humble opinion and my work experience with git, staging area is not the same as index. I may be wrong of course, but as I said, my experience in using git and my logic tell me, that index is a structure that follows your changes to your working area(local repository) that are not excluded by ignoring settings and staging area is to keep files that are already confirmed to be committed, aka files in index on which add command was run on. You don't notice and realize that "slight" difference, because you use git commit -a -m "comment" adding indexed and cached files to stage area and committing in one command or using IDEs like IDEA for that too often. And cache is that what keeps changes in indexed files. If you want to remove file from index that has not been added to staging area before, options proposed before match for you, but... If you have done that already, you will need to use

Git restore --staged <file>

And, please, don't ask me where I was 10 years ago... I missed you, this answer is for further generations)