How to manage configuration files when collaborating?

I'm writing a short script with a few simple variables at the top of the page. I want to work on them with a friend, but we aren't sure how to manage the variables needing to be changed after pulling each time for one of us, adding unnecessary junk to git status. I thought about just creating different named branches for each of us, and then the master will just have example usernames set, but it seems silly to have to do all that extra work merging. We could have the variables passed to the script as options, but that isn't desired, nor is separating it out to another separate configuration file. It would be great to have something like a .gitignore but for only ignore a few lines in a file.

How can this be elegantly managed? How is this problem usually managed?

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.

Python/Django-specific solution is to have a shared settings.py files that is checked into the repository, and a local settings_local.py imported at the end of settings.py, that overrides some of the settings with machine-specific values.

In my case, I have "config" variables in a separate (small) file as do all the other developers on the team. Things like my database location etc. are kept there. We put the name of this file in our .gitignore so that it's not version controlled but checkin a "sample_config" file so that newcomers can make a copy and use it for their own purposes.

Other options (not elegant but may be helpful):

• Use git stash and git stash pop for your config file
• Have a branch named, say, config which has your local config file changes and then use git checkout config <your config file>

Second option is good if you need to keep the local config changes in the repo (somewhere).