办法其实很多，有两种较常用。

第一种是配置文件不提交真实内容，只提交一个模板文件。每个开发者克隆之后按照自己的环境补完配置文件，这样自然而然就独立出来了(需更改文件名并忽略有效配置文件)。

如果配置文件很大配置项很多，此法会让每一个人都觉得很麻烦。可以进一步把需要独立配置的选项单独分一个文件，可以共享的配置文件提交，需要独立的配置文件则模板化，这样可以省点事。不过使用配置的时候需要对两类文件进行合并处理——这个可以写脚本来做。更进一步的，可以允许独立配置文件覆盖同名配置项，这样还可以做到配置可自定义化。

第二种方法则是换一个思路，配置文件正常提交，不用分也不用改。但凡遇到敏感信息的一律不写明文，可以用比如说系统环境变量来取代。每一个开发者需要在克隆代码之后设定必须的环境变量(这件事情本身可以单独来管理，和具体项目不牵扯)，而项目本身的运行则依赖这些环境变量的存在及其验证有效性等等。

第一种方法在各种开源项目里用的比较多；第二种方法则有一定的门槛，所以多用于固定团队项目。个人偏好第二种，因为我可以简单地使用脚本来控制一切，而且敏感信息独立于项目，安全性更高一些(第一种方法里，不巧总能碰到坏事的小白……)，可重用性也更高(比如说多个项目都要用到数据库，我只需要本地设置一次相关的环境变量，这些项目都能使用)。