您如何处理源代码管理中的配置文件?

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 a dev, prod and stage versions. How do you deal with this in source control? Not check in this file at all, check it with different names or do something fancy altogether?


+1 absolutely for stressing that configuration should still be versioned

And if username is not reliable for whatever reason, then you can have a single file with only one line giving the name of the override config file. This way, there is very little (as in about 10 characters or so) which are not version controlled. And the README file could explain that you need to make that file.

I always think that configurations should be kept separate from code. I've worked at places which require so many configurations for one repo that Git just gets overwhelmed with config files. Not saying that configs shouldn't be versioned, they belong elsewhere like an artifact manager. Config is not code, they're settings for code.

Configuration files may contain sensitive information like passwords that should not be versioned. Or do you want to grant every developer access to your production environment? I think it is better to just version a "master config" and override it in specific environments.

I use this approach, I just have a main.php.tmpl and when I checkout a new copy just copy it to main,php. I add the main.php file to the ignore list to avoid commit it by accident.

But when the developers testers push into the mainline, their changes to the template file will be pushed in as well. No?

Unless there's a solution to Nick's comment, this will not work from what I see. Or maybe explain what flow model you're using which would solve the issue.

I agree with the template approach with any necessary adjustments baked in at build time. However on the branching topic... What if there were multiple templates (dev, test, etc.) and developers simply omit changes from their commits. Not foolproof but could work with cooperation.

This works extremely well if there are only a few difference between the environment (ie connection strings)

and assuming there are not 100s of developers all putting their customized settings there as well (it would still work, but be very cumbersome)