Oh dear, you aren't supposed to commit configuration files? Is this a security thing? What's the proper way to distribute config files to to the server and other developers?
"sometimes php developers commit configuration files and things that are used in production where they shouldn’t be."
Not sure if I'm parsing this correctly. Should the files not be in production or should they not be committed? Is this just about overwriting the development configuration in the config file?
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?)
Heroku has made it very easy for multiple developers to have custom, local environment variables with Foreman, and their gem doesn't necessarily have to be used with Heroku for local machines. [1]
We use Heroku exclusively, so they manage configuration variables for us, but adopting an environment-variable structure on any UNIX architecture should be reasonably straight forward.
The nice thing about this setup is that many "if ( development && developer_is_bob ) or staging" conditionals disappear, because your app just swallows in the environment-specific variables by magic. They also help avoid "oops-I-didn't-mean-to-check-that-in" errors: yesterday a client's Login with Facebook button was down for a few hours because the client's developer developer swapped out the omniauth config by hand, then committed the new Facebook app ID along with the rest of his changes. I've told him to use Foreman in the future, which would have nicely avoided the problem.
As to your first point, there's no reason you can't version-control your configuration files on your servers, but keep them in a separate repo which your juniors, open-source contributors, or the thief who ran off with your developer's computer don't have access to.
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.
That's better than the converse (default is prod, yikes!) but there's a risk of a prod server using the dev config, which might appear to work unless your dev environment is firewalled off. I prefer having an invalid or unusable config checked in, so the system doesn't even come up until I deploy the config I intend to use over it.
"sometimes php developers commit configuration files and things that are used in production where they shouldn’t be."
Not sure if I'm parsing this correctly. Should the files not be in production or should they not be committed? Is this just about overwriting the development configuration in the config file?