# How to delete a file from a Git repository, but not other users' working copies

Suppose you have, by mistake, added your IDE's project folder (you know, these `.idea` folders with all kinds of local paths and configuration data and settings in it) to the Git repository of your project. (We're talking about a whole folder here, but the same rules apply to individual files as well.)

Of course, you only realize that two days after the fact and have already pushed it, and your colleagues have already pulled it. They use the same IDE as you do, so whenever they change a setting or fix paths, they can either

* commit that, causing nasty merge conflicts for you and others or
* ignore the changes and carry around a modified file until the end of time without ever committing it.

## Why .gitignore won't help

So the first thing you usually do is thinking "aw shit, I fucked up, better add the folder to `.gitignore` right now". And after you do that, surprise: Changes to files which are already committed will still cause that file to appear as modified in Git.

This is because `.gitignore` by design only works for files which are not tracked, i.e. not yet in the repository. If you add a file to the `.gitignore` after it has already been committed or if you force-add a file (`git add -f`) which might otherwise be ignored, this file will be tracked just like any other file in your project.

## Deleting the files from the repository

So, the next thing you would try is to delete the folder from the repository. Then, Git won't track it anymore and the `.gitignore` will cause it not to be added again unintentionally.

However, how do you delete it _just_ from the repository? Because you don't want to lose your IDE settings of course. The folder should still be available on your machine after, like, "un-committing" it.

(Of course you could just copy it somewhere else, tell Git to delete it, commit that and than put the copy back. But that would be cheating.)

Turns out there is `git rm --cached` which does exactly that: Stage "file X has been deleted" without actually deleting it on your disk. So you simply run `git rm -r --cached .idea`, commit that and be done, right?

Wrong.

## How not to be hated by your colleagues

When others pull this "pseudo-deletion" you just committed, their local Git doesn't know that you kept a copy of the folder and didn't _actually_ delete it. So what Git on their machines is going to do is to happily delete the folder in their working copies, causing their IDE to become somewhat unhappy. How can you keep Git from doing that?

Well, to be honest, you can't. The change you committed _will_ cause Git to delete the folder on each and every colleague's machine.

Except … well, except if you delete it before Git does!

### Pseudo-delete it before Git deletes it

If the other developers run `git rm -r --cached .idea` and commit that to their local trees _before_ pulling your changes, Git will see that these two changes are equivalent (both "delete" the folder) and thus not try to delete it again.

So, that would be the first solution. Tell all your coworkers that at 3pm you're going to delete the `.idea` folder and that they should `git rm -r --cached .idea` as well and commit that before pulling or merging your changes. (Make sure the folder is in `.gitignore` first.) But if that's not feasible or if some didn't get the memo, there's a second possibility:

### Just restore it

If the folder gets deleted on their machine, they can simply restore it again. After all, this is version control!

There is the `git checkout <tree-ish> <file(s)>` command that asks Git to place any file from any point in time in your current working copy. So if the last commit that your coworker pulled from you caused the `.idea` folder to be deleted, she could just say `git checkout HEAD^ .idea` and get it back from the version before. If there is more than one commit in between, first find the commit where the file has been deleted (`git log --stat --diff-filter=D` might be handy) and then use the commit before. So, for example, if the folder was deleted in commit `c4f3d00d`, use `git checkout caf3d00d~1 .idea`.

*But wait! There is one more absolutely crucial step!*

Because after you've used `git checkout` to restore the deleted folder, Git will add that folder to the index and stage it for commit! Yes, even when it's in `.gitignore`. (And no, there's no command line switch to keep it from doing that.) Which means, if you're not careful, you might end up committing the IDE folder _again_!

Luckily, this is pretty easy to do. Simply do a `git reset HEAD .idea` after the checkout and everything is fine. And since the folder is in `.gitignore` (you've added it there, didn't you?), Git won't add it back again.