我继承了一个项目，我们正在使用git。我们有许多环境（开发，测试，产品）。前一个团队基本上使用相同的帐户，密码，sid等在每个实例上重新创建了所有内容。唯一改变的是/ etc / hosts中的主机名映射。这样它就可以连接到不同的数据库服务器。
现在，这会产生一个问题，因为我不能，例如复制一个模式，以便开发人员可以使用与主开发服务器相同的数据库实例来运行实验。我基本上必须在另一台主机上创建一个新的数据库实例，并将/ etc / hosts更改为指向该新服务器。
虽然这是目前的工作设置，但我正在尝试找到一种方法来为每个实例维护不同的配置文件。 ie：取决于分支的applicationConfig.xml的不同版本。我猜测有人可能认为在回购中保留数据库凭证并不是一个好主意，但我们可以暂时忽略它。
另一种可能需要具有不同版本文件的情况可能是调试。假设我正在使用javascript记录器框架，并且我添加了我不希望随生产版本发布的调试代码。我不想在开发/测试时添加记录器内容，然后在发布之前再次将其删除。有人可能会忘记这样做。
处理不同分支的文件的不同“版本”的正确方法是什么？有没有办法让一个分支与master上的最新代码保持同步，但是有一些配置/代码文件被更改了？我不希望它自动保持同步，但我希望能够不合并配置文件（或它们的一部分），而不是完全忽略它们（？）。例如：不合并第6,7行（db用户名和密码），但将其他更改合并到文件中。
答案 0 :(得分：28)
听起来你应该读懂git属性。 Check out the section at the bottom of this page
如果项目中的某个分支发生了分歧，那么这很有用 专业，但您希望能够从中合并更改， 而你想忽略某些文件。假设您有数据库设置 文件名为database.xml，在两个分支中是不同的，而你 想要在你的其他分支中合并，而不会弄乱数据库 文件。
答案 1 :(得分：2)
正如您所说，将配置设置存储在代码中并不是一个好主意。特别是，在我看来，您的开发人员甚至不应该知道生产数据库的凭据。
我们在这里做的是，在每台服务器上，我们有预定义的环境变量，指向具有必要凭据的配置文件。由于我们在这里使用Java，因此这是一个像database.properties这样的文件，这个文件永远不会在版本控制系统中。
这也可以在每台服务器上使用不同的设置和不同的凭据