If the file is already pushed to the remote repository (and it obviously is, because you pull and get updates on is), then .gitignore
won't help. .gitignore
is intended for the cases where you don't want to even commit the file to git in the first place.
What you describe is something that goes against git's intuition.
So you pull from the remote repo, and someone else changes the file - great, this means that there was "some work done" on this file.
Git, being a source code management system, is perfectly fine with that. Now you say that meanwhile you've also changed the file. But now what do you intend to do with this change? If you want to commit this change a part of you work, then you have a conflict - something that you should resolve by yourself, so that the file will include both changes done by other people and your changes.
If you don't want to commit the file, then what's the point?
Of course you can copy it aside, pull everything and "paste" the file, at the end git kind of assumes that you will keep your changes in git.
Now, having said that, you can "force" git to deal with conlicts in a way that it will always favor your changes over those done in remote repo.
You can specify a merge strategy during the git pull
operation as a parameter, probably you're interested in a strategy called "ours".
You can read about merge strategies Here