Take the 2-minute tour ×

from the page http://gitref.org/basic/ it explain

git rm will remove entries from the staging area. This is a bit different from git reset HEAD which "unstages" files. By "unstage" I mean it reverts the staging area to what was there before we started modifying things. git rm on the other hand just kicks the file off the stage entirely, so that it's not included in the next commit snapshot, thereby effectively deleting it.

By default, a git rm file will remove the file from the staging area entirely and also off your disk > (the working directory). To leave the file in the working directory, you can use git rm --cached.

but i still can't tell what exactly is the difference between git rm --cached asd and git reset head -- asd...

share|improve this question
add comment

3 Answers

up vote 49 down vote accepted

There are three places where a file, say, can be - the tree, the index and the working copy. When you just add a file to a folder, you are adding it to the working copy.

When you do something like git add file you add it to the index. And when you commit it, you add it to the tree as well.

It will probably help you to know the three more common flags in git reset:

git reset [--<mode>] [<commit>]

This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and the working tree depending on <mode>, which must be one of the following:


Does not touch the index file nor the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.




Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.

Now, when you do something like git reset HEAD - what you are actually doing is git reset HEAD --mixed and it will "reset" the index to the state it was before you started adding files / adding modifications to the index ( via git add ) In this case, the working copy and the index ( or staging ) were in sync, but you made the HEAD and the index to be in sync after the reset.

git rm on the other hand removes a file from the working directory and the index and when you commit, the file is removed from the tree as well. git rm --cached however removes the file from index alone and keeps it in your working copy. This is the exact opposite of git add file In this case, you made index to be different from the HEAD and the working, in it that the HEAD has the previously committed version of the file, working copy had the las modification if any or content from HEAD of the file and you removed the file from the index. A commit now will sync the index and tree and the file will be removed.

share|improve this answer
I notice that after git rm --cached the git diff command doesn't show any diff, but git diff --cached shows the diff, as if it is still cached. The git status however shows the file as being Untracked. Seems kind of inconsistent. –  haridsv Nov 6 '11 at 19:15
Never mind... I should have used git reset --mixed. I was a little confused by the statement that git rm --cached is the opposite of git add. Taken literally, it is incorrect and could cause damage. In my case, I used git add to add a modified file to the staging area and wanted the opposite of "that add" not the initial add of the file. +Greg Hewgill's answer helped me get a clearer picture. –  haridsv Nov 6 '11 at 19:19
I find the use of working copy, tree, and working tree a little confusing. Is the working tree the working copy, or tree ? –  Nealv Sep 23 '13 at 9:00
add comment

Perhaps an example will help:

git rm --cached asd
git commit -m "the file asd is gone from the repository"


git reset HEAD -- asd
git commit -m "the file asd remains in the repository"

Note that if you haven't changed anything else, the second commit won't actually do anything.

share|improve this answer
add comment

git rm --cached file will remove the file from the stage. That is, when you commit the file will be removed. git reset HEAD -- file will simply reset file in the staging area to the state where it was on the HEAD commit, i.e. will undo any changes you did to it since last commiting. If that change happens to be newly adding the file, then they will be equivalent.

share|improve this answer
add comment

Your Answer


