Convenciones para files de configuration en software de código abierto

Estoy desarrollando una aplicación PHP que necesita acceso a una database y estoy usando git para el control de versiones. Quiero crear un file de configuration que almacenará el nombre de usuario, la contraseña y otras configuraciones específicas de la aplicación. Sin embargo, no quiero arriesgarme a comprometerlo con mi repository.

Actualmente administro esto creando el file settings.ignore.php en el mismo directory y listándolo en mi file .gitignore.

settings.php:

<?php $dbUser = ''; $dbPass = ''; $dbName = ''; include 'settings.ignore.php'; 

settings.ignore.php:

 <?php $dbUser = 'admin'; $dbPass = 'secret'; $dbName = 'database'; 

¿Es esta la mejor o la forma más común de resolver el problema?

En general, la configuration de configuration debe almacenarse fuera del código de la aplicación.

De esta manera, simplemente puede actualizar la aplicación, sin tocar la configuration. Por ejemplo, eche un vistazo a la estructura de carpetas de un proyecto de Symfony:

 app/ # configuration, log files, cache bin/ # "binaries", ie helper scripts for the command line src/ # YOUR application code, ie code you wrote specifically for your app vendor/ # 3RD PARTY code, ie Symfony and other external code web/ # public files: images, JS, CSS, font files 

La configuration es específica del entorno y, dependiendo de cuál sea, se puede encontrar en diferentes files:

 app/config/config_dev.yml # config for your development environment app/config/config_test.yml # config for your unit tests app/config/config_prod.yml # config for production/target environments app/config/config_longjon.yml # if you want, set up your own env. type app/config/config.yml # common config for all of them, inherited 

Por cierto, como ve, Symfony no usa files PHP para la configuration, sino YAML (o XML). En este caso, es por supuesto muy importante almacenar la configuration fuera de la raíz del documento.

Recomendaría download una cantidad de frameworks ampliamente utilizados escritos en diferentes idiomas, tal vez leer su documentation, para ver cómo manejan esta categoría de preguntas.

Por lo general, han pensado mucho en estas cosas, y muchos desarrolladores avezados solían participar.