How to manage configuration files when collaborating?

You can’t easily just ignore changes to particular lines of a file, I’m afraid, so you’re probably stuck with having a separate configuration file. Below I’ve listed two typical ways of dealing with this, and one slightly more exotic one:

Have a sample configuration file in git

Here, you would keep a file config.sample in git as an example, but the application would actually use the values in a file config which is in .gitignore. The application would then produce an error unless config is present. You have to remember to change values in the sample file when you add new configuration variables to your personal config file. In this case it’s also a good idea to have your application check that all the required configuration variables are actually set, in case someone has forgotten to update their config file after changes to the sample.

Have a file of default values in git

You keep a file config.defaults in git, which has sensible default configuration values as far as possible. Your application first sources configuration from config.defaults and then from config (which is in .gitignore) to possibly override any of the default values. With this method, typically you wouldn’t make it an error for config not to exist, so the application can work out of the box for people who haven’t bothered to create config.

Using a single configuration file with –assume-unchanged

A third possibility, which I wouldn’t recommend in this case, personally, would be to have a single configuration file which is committed in git, but to use git update-index --assume-unchanged <FILE>, to tell git to ignore changes to it. (This is described further in this useful blog post.) That means that your local changes to the configuration file won’t be committed with git commit -a or show up in git status.

Leave a Comment