只写过业务代码，没在生产环境玩过服务器运维的小盆友（也不排除有很多老手甚至所谓架构师）可能潜意识里默认认为配置文件“只能”或者“应该”从项目路径结构（当前目录或者下面的子目录）读取，所以在这个问题上会犯难。其实哪有这么愁呢？
方法一，程序里指定从 /etc/<my_project>/<some_item>.conf 这样的 site-wide global path 里读取配置，开发机和生产环境各写各的配置，互不影响，提交的代码里根本不包含配置文件，而且做部署的时候也不会覆盖现有的配置文件。缺点是如果配置文件语法、语义有版本变化，需要生产环境的运维人员配合做升级。
方法二，做两个不同的 profile ，但都是从项目内部路径读取配置。开发机用开发的 profile ，部署到生产环境用生产的 profile 构建打包。两个 profile 的配置文件加入.gitignore 确保不会提交。缺点是每次在新的开发机上 clone 出来需要自己准备配置文件。
方法三，做两个不同的 profile 。开发机用开发的 profile ，从项目内部路径读取配置。部署到生产环境用生产的 profile 构建打包，不打入配置文件，而是从 site-wide global path 里读取配置。开发 profile 的配置文件加入.gitignore 确保不会提交（其实提交了也无所谓）。集一和二的部分优缺点。
当然，做不同 profile 也有多种实现方式。一般 Java 项目是在构建时区分，某些脚本语言的项目往往在运行时通过读取环境变量或者命令行参数来区分。只要能分开，都不是大问题。