在同一个仓库中处理不同的配置文件版本

Question

我们有一个 git 存储库，它以 git-flow(ish) 类型的方式设置——我们有 3 个“主线”分支，开发、发布和生产。我们的工作流程是一段新代码进入开发阶段，周期为两周。一旦这两周过去了，开发就变成了“发布”，此时它被测试并修复了一些东西，但没有应用新功能。 2 周后，release 被部署，并成为生产分支，它并没有真正被触及（除非在紧急带外修复的情况下）

因此，我们在本地有 3 个版本的数据库来跟踪 3 个不同的分支。我们往往会有很多架构流失，因此在 dev 分支中发生的更改可能会破坏发布或生产中的内容是很常见的。

问题是，如何在同一个 git 存储库中管理 3 组不同的配置文件？目前，我们正在做的是 .gitignoring 它们，并在每个人的机器上保留 3 个本地版本的代码库。但是，由于多种原因，这并不是很理想，如果我们可以拥有一个版本的 repo 并在分支之间切换，那就太好了。

我想我正在寻找一种将文件签入分支的方法，并将其保留在那里，但不会在主线分支的合并之间被拾取。这样一来，在 dev 上可能会有一个版本，在 release 上会有一个版本，在 master 上会有第三个版本，但每个版本都将与其他版本隔离。有点像 .gitignore 用于合并。

这可能吗？有没有人遇到过这个？ （不敢相信只有我们）你是怎么解决的？

Answer 1

Manojlds 是对的：单独的配置文件是最好的（那样​​没有合并问题）。

最好将这些“值配置文件”与内容过滤驱动程序结合起来，以便在结帐时自动生成正确的和最终（但非版本化）配置文件的“涂抹”脚本。

请参阅问题“Something like gitignore, but not gitignore”了解更多信息。

Answer 2

如果您谈论的是环境配置，您可以为每个环境配置一个配置，例如 dev.config、test.config、production.config 等。可以在 dev 分支上对 dev.config 进行更改。一旦它通过测试并且发布时间到来，发布中的测试/生产配置可以适当地更新和测试。为所有环境设置一个配置是没有意义的。