git deployment strategy

http://nicolasgallagher.com/simple-git-deployment-strategy-for-static-sites/

You can still ignore a tracked file. All this means is that you can't accidentally replace the existing version with a modified version, without using the "force"  flag. It's meant for exactly this situation, where a file must be tracked but may be charged during the build but those changes should not be accidentally committed.

Another option is to use the assume unchanged flag on the update index command.

http://git-scm.com/docs/git-update-index

There are very few work flows you can't support with git, but sometimes it does mean experimenting a little to find the right combination of commands and flags.

>> Can you give a deeper explaination on your seperating repo proposal?
At the moment you push changes to one repo and then use branches to switch between testing and production. I am suggesting you have one repo for testing and one for production. You push all the untested code into the testing repo. Once it's passed testing you push those changes into the production repo. You only every release from the production repo.

The workflow would be something like this...

[make changes] --- push ---> (test repo) >> [test changes] --- push ---> (prod repo) >> [deploy]

This is just a suggestion and it would probably need a bit of thinking through before you decide it would be the way to go. I'm not saying it is your best solution; rather, I offer it as something to consider if using the single repo with branches approach doesn't meet your workflow needs.