How do you deal with configuration files in source control?

Question

Let\'s say you have a typical web app and with a file configuration.whatever. Every developer working on the project will have one version for their dev boxes, there will be

Answer 1

I don't think there's a single solution that works for all cases as it may depend on the sensitivity of data in the config files, or the programming language you're using, and so many other factors. But I think it's important to keep the config files for all environments under source control, so you can always know when it was changed and by whom, and more importantly, be able to recover it if things go wrong. And they will.

So here's how I do it. This is for nodejs projects usually but I think it works for other frameworks and languages as well.

What I do is create a configs directory at the root of the project, and under that directory keep multiple files for all environments (and some times separate files for each developer's environment as well) which are all tracked in source control. And there is the actual file that the code uses named config at the root of the project. This is the only file that is not tracked. So it looks like this

root
|
|- config (not tracked)
|
|- configs/ (all tracked)
    |- development
    |- staging
    |- live
    |- James

When someone checks out the project he copies the config file he wants to use in the untracked config file and he is free to edit it as he wishes but is also responsible to copy these changes before he commits to the other environment files as needed.

And on servers, the untracked file can simply be a copy (or reference) of the tracked file corresponding to that environment. In JS you can simply have 1 line to require that file.

This flow may be a little complicated at first but it has great advantages: 1. You never have to worry about a config file getting deleted or modified on the server without having a backup 2. The same if a developer has some custom config on his machine and his machine stops working for any reason 3. Before any deployment you can diff the config files for development and staging for example and see if there's anything missing or broken.