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?
Answer
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.