An example scenario might play out thusly: Fred checks in the production configuration credentials (lets say mysql configuration for this example) in a file called passwords.php. Senior developer Bob Van Gogh checks out the project but needs to connect to his local mysql instance to develop. He edits the configuration file and hacks away on his feature. Somewhere along the way he accidentally commits passwords.php with his changes. Eventually his code is deployed and suddenly the app servers can't connect to the database. Bob's no good at football but he's a good developer and now thanks to that accident his reputation is tarnished beyond the football pitch too.

Configuration like that should be managed by something that isn't susceptible to these accidental changes.

As you mention it, security is an issue too. The fewer people who know the passwords to anything the better and the more you can keep the passwords from going over the wire the better.

Configuration files probably include database passwords, AWS secrets, API keys, maybe even SSH keys. Fairly clearly:

1. They're really important and change periodically in sync with the rest of the app. 2. They shouldn't be in a public repo under any circumstance, EVER. 3. You probably don't want every single developer having access to your production database passwords.

Point 1 argues strongly in favour of putting them into version control for all the same reasons you'd put anything into version control.

Point 2 and 3 argues for putting them in your .gitignore (or equivalent) and copying files around by hand (or via a fabric script or what have you) during deploys.

Common wisdom seems to be that point 2 and 3 outweighs point 1, and for open source projects which live in public repos it probably should. Ditto for large enterprisey projects. But for a startup, working on a non-open source project, I think point 1 massively outweighs everything else.

As an example, the most common advice for configuration for django apps is to have a settings.py which imports a settings_local.py; you then put settings_local.py into .gitignore, and in every environment you create a new settings_local.py and add the local settings (database connection strings, template paths, whatever) into it. I started out doing it that way too, but I've recently reversed it: Now I have a settings_dev.py, settings_staging.py, etc, each with the specific environment settings, and each of which imports the common settings from settings.py, and all of which are in source control. Now I can checkout any branch or version of my app, and have some confidence that I've got the right settings to run it in whatever environment I want.

(I see philjackson has listed another reason for being careful with config files, but I'm not sure I agree. I'd say he's basically giving an argument for using different config files in different environments, and generally being a bit organised. And if there is any risk of developers fat fingering the config files, isn't that an argument to have them in version control so you can fix it easily?)

All phpers are now offended? haha, must be true than!