how to avoid to overwrite a file in git

Question

I have some repos on git shared with my colleagues and in which I need a configuration file used only for local development. I pushed the default configuration file to the master and then add it to the gitignore. After, I cloned the repo to my local pc and modify the configuration file to fit my environment, but when I try to commit the changes, git try to commit also the changes on the configuration even if I already add it the gitignore.

Answer 1

You can accomplish this using the skip-worktree flag on a per-item basis. Here' the command that tells Git to not recognize changes to a particular file:

git update-index --skip-worktree <file>

(UPDATE: I just checked out the link that @mkreiger1 posted in a comment. This pointed out to me that my original answer might have been less than correct. It mentioned the use of the --assume-unchanged flag. I realized that my group did in fact look at both options and dismissed the use of both of them. That link is worth checking out. The goal of my answer is to offer my team's take on this issue, which might save you some time and effort.)

This solution is a pain if the underlying remote version of the file changes frequently. When the file changes on the remote, you have to move your local copy out of the way, then update your local repo, then merge your own version of the file back into the new remote version, and then (I believe) reapply the above flag. The reason for this is that the abovementioned flag does not change the behavior when updating from a remote repo. If you have uncommitted changes to a tracked file, you will get an error from Git regardless of if this flag is set or not.

This solution is also problematic when switching branches, if the contents of the file is different in each branch, which I assume will just about always be the case.

I know all this because my team recently had this exact issue come up. We decided that it was not worth trying to do this with a single config file location. Instead, we modified our code to look in multiple places for configuration files. The "developer location" of the files wins out over the Git-tracked location on a file-by-file basis. We ended up defining a config directory that exists at the top level of a developer's home directory. This location is queried first. If the file being searched for exists in this directory, then that version of the file is used, and the Git-tracked location is not queried at all for that file.

If the remote version of a config file changes infrequently, then this might be a viable solution. You may want a developer to know when this occurs and force them to take action to reapply their local changes in a very conscious way. The error message from Git is constructive in this case. But if minor changes are made frequently that the developer doesn't necessarily need to be aware of, then this solution will cause more pain than it is worth.