233

On SVN, removing something from the filesystem directly (rather than using svn) created a load of headaches.

I haven't found this to be an issue when using git, but I notice that git has its own rm implementation (git rm).

What is the difference between rm and git rm?

danronmoon
  • 3,814
  • 5
  • 34
  • 56
cjm2671
  • 18,348
  • 31
  • 102
  • 161

9 Answers9

326

If you just use rm, you will need to follow it up with git add <fileRemoved>. git rm does this in one step.

You can also use git rm --cached which will remove the file from the index (staging it for deletion on the next commit), but keep your copy in the local file system.

Andy
  • 44,610
  • 13
  • 70
  • 69
  • 2
    Good answer. I was able to use `git reset --hard` and then do a checkout of master to get out of detached head state because I knew I didn't have any uncommitted changes. If you haven't committed your changes you may want to do a git stash, but I'm relatively new to git so I don't know the exact command. If you have come here in or after 2014, I hope this answer was useful to you. – Eric Hepperle - CodeSlayer2010 Nov 24 '14 at 19:14
  • @Andy - If I used `rm` (instead of `git rm`) and deleted many files using it, and now don't want `git` to track those. Is there a way to revert changes? I want `git` to tread my `rm` as removed since I didn't use `git rm` in the first place. – Chetan Arvind Patil Jan 30 '18 at 17:43
  • It would be nice if this were clearly spelled out in the docs online (it may be there, but it's obviously not obvious or this question wouldn't have been asked). It would be nice for users to know that they're not doing anything wrong if they go the OS rm route. And there are reasons to go the OS route. E.g. if you need to delete a file to test that something works before committing the change, the OS route is a bit safer than using git rm, as in the git case you have to unstage the action, whereas in the OS option you just have to fetch (I believe). – bob Apr 23 '20 at 21:12
  • 1
    I still don't understand it. – Tom Smykowski Aug 02 '22 at 16:40
15

Removing files using rm is not a problem per se, but if you then want to commit that the file was removed, you will have to do a git rm anyway, so you might as well do it that way right off the bat.

Also, depending on your shell, doing git rm after having deleted the file, you will not get tab-completion so you'll have to spell out the path yourself, whereas if you git rm while the file still exists, tab completion will work as normal.

hammar
  • 138,522
  • 17
  • 304
  • 385
10

git rm will remove the file from the index and working directory ( only index if you used --cached ) so that the deletion is staged for next commit.

manojlds
  • 290,304
  • 63
  • 469
  • 417
9

Adding to Andy's answer, there is additional utility to git rm:

  1. Safety: When doing git rm instead of rm, Git will block the removal if there is a discrepancy between the HEAD version of a file and the staging index or working tree version. This block is a safety mechanism to prevent removal of in-progress changes.

  2. Safeguarding: git rm --dry-run. This option is a safeguard that will execute the git rm command but not actually delete the files. Instead it will output which files it would have removed.

Joe
  • 2,386
  • 1
  • 22
  • 33
6

However, if you do end up using rm instead of git rm. You can skip the git add and directly commit the changes using:

git commit -a

Struggler
  • 672
  • 2
  • 9
  • 22
3

Remove files from the index, or from the working tree and the index. git rm will not remove a file from just your working directory.

Here's how you might delete a file using rm -f and then remove it from your index with git rm

$ rm -f index.html
$ git status -s
 D index.html
$ git rm index.html
rm 'index.html'
$ git status -s
D  index.html

However you can do this all in one go with just git rm

$ git status -s
$ git rm index.html
rm 'index.html'
$ ls
lib vendor
$ git status -s
D  index.html
basicxman
  • 2,095
  • 14
  • 21
2

I guess I finally get it

If you make changes to a file file_a.txt

and then do

git add file_a.txt
rm file_a.txt
git commit -m 'Commit message'

Although the file is removed from the working directory (i.e from disk, or moved to the trash bin), it is not removed from the staging area, therefore the changes in the staging area (i.e index) will be committed

if instead you do

git add file_a.txt
git rm file_a.txt
git commit -m 'Commit message'

The file will be deleted from disk and from the staging area, so changes will not be committed

Now if after your last commit, you do either

rm file_a.txt
git commit -m 'Commit message'

or

git rm file_a.txt
git commit -m 'Commit message'

It should make no difference, because you did not add any changes to the staging area or index, so there is only on copy of the file in the working directory, so both command will have the same impact

So in summary rm will just remove from disk, not from staging area git rm will remove from both disk and staging area (a special git area that you cannot reach by regular windows or linux commands)

Ali
  • 21
  • 3
  • Great point, adding slight difference of `rm` which is prepended with `git` as `git rm...` underlining the differences in between, thanks @Ali ! – projektorius96 Nov 02 '22 at 15:18
2

When using git rm, the removal will part of your next commit. So if you want to push the change you should use git rm

keis
  • 113
  • 7
0

git rm is safer than rm in some cases when user is using case-insensitive system like Windows or MacOS. The followings are a certain examples.

Let's say that your git repository on case-insensitive system has a committed file named foo.js and you will be running into a error when running git rm Foo.js. But not with rm Foo.js instead.

liuliang
  • 395
  • 1
  • 3
  • 14