在git中，dev和production分支之间的区别在哪里？

Question

我有一个项目，我管理一个git仓库。我们使用progit分支策略（如接受的答案中所述，这里是Git branch strategy for small dev team），其中一个分支是生产分支，另一个分支是开发/测试分支。我们使用结构部署代码。

当我们准备用git制作新的产品发布版时，我们将开发/测试分支合并到生产分支中，然后使用结构部署生产分支。问题在于开发和生产之间存在代码差异 - 一些徽标发生变化，一些不同的数据库主机/凭证等等。我一直在保存一个包含差异的.patch文件，并在构建生产环境时使用这个补丁来构建补丁程序，但这种方式并不能很好地工作。特别是，如果修补程序周围的一些代码发生了变化，则完全失败 - 修补程序无法应用，并且我的部署中止。

我一直在想，如果我不应该直接将所有更改应用到生产分支？这有什么缺点？

我关心的一个特殊用例是，如果我们需要做一个修补程序。我们目前通过从生产环境中分支，进行更改，然后将该分支合并到开发和生产中来实现这一点。如果生产分支与开发分支不同，那么当修补程序合并到开发中时，这些更改是否会被拉入开发分支？

Answer 1

你的问题基本上归结为“如何在一个分支中进行更改，然后当我合并到另一个分支时不会传播该更改？”。这相当简单。在这一点上，我假设你的生产分支基本上只是一系列合并，无论是从开发分支，或从一个修补程序分支。所以大概从你的开发分支做git merge production不会做任何改变。鉴于此，请继续并对生产分支进行更改。现在提交它们。现在结帐开发分支并运行git merge -s ours production。这基本上意味着“从生产合并，但拒绝所有他们的变化”。这将创建合并提交，但实际上并不会触及您的开发分支。

一旦合并后，您现在可以合并的分公司生产纳入发展（或者更确切地说，合并修补程序分支）不用担心，因为你的生产只承诺现在已经“合并”成发展（尽管事实代码更改本身被拒绝）。所以合并你的修补程序分支将不会拉入生产专用代码。

一旦你完成了这个任务，唯一一次你需要返回并重新应用这个技巧就是如果你进行更多生产性更改。如果您在开发分支上进行与仅生产更改相冲突的更改，那么在将开发合并到生产中时，您可以继续并毫无问题地接受冲突的生产方。

Answer 2

我也有这个请求在开发分支和生产分支。我不认为git合并 - 我们的**是一个很好的解决方案，因为它可以确保后面的一个合并不会被覆盖，并且在那之后它将导致dev和生产之间的父亲关系。你必须每次都使用git merge -s我们的**，这会使日志图变得非常丑陋和毫无意义。

因此，我建议使用

git的樱桃采摘

。这可以确保你想要的内容。