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.
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.
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.
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!
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:
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.