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

我们有一个以git-flow（ish）类型的方式建立的git仓库 - 我们有3个“mainline”分支，dev，release和production。我们的工作流程是，一段新的代码进入dev，其周期为两周。一旦这两周过去了，dev就变成了“发布”，在这一点上它已经过测试，并且固定了它，但是没有新的功能被应用。在此之后的两周内，发布会被部署，并成为生产分支，但实际上并未触及（除非紧急带外修复）在同一个仓库中处理不同的配置文件版本

因此，我们在本地有3个版本的数据库跟踪3个不同的分支。我们倾向于有大量的架构流失，所以在dev分支中发生的变化可能会破坏发布或生产中的变化是很常见的。

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

我想我正在寻找一种方法来检查一个分支中的文件，并让它停留在那里，但不会在主线分支合并之间拾取。这样就可以在开发版本上发布一个版本，在主版本上发布一个版本，但每个版本都可以与其他版本分开。有点像.gitignore合并。

这可能吗？有没有人遇到过这个？（不能相信我们是唯一的）你是如何解决它的？

来源

2012-02-06 Matt Briggs

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

来源

2012-02-06 04:54:30 manojlds

所以这就是我们所拥有的东西，但是我们需要通过qa中的东西来分割我们的配置，并且积极开发中的东西，并且在定期切换它们之间进行切换。一种不必重新命名3-4个文件的方法，或者在我高清上的不同分支上安装2个回购站来完成切换 – 2012-02-06 06:26:40

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

最好是那些“价值配置文件”与内容过滤驱动，以结账自动生成（结合有“污点”脚本的权利和最后（但非版本）配置文件。

查看“Something like gitignore, but not gitignore”更多的问题

来源

2012-02-06 06:30:43 VonC

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

回答

相关问题