GitFlow：先合并到主分支还是在生产发布之后？

Question

学习GitFlow时，我有一些担忧，在我阅读的所有文档/文章中都没有提到。

在某个时间点，需要将develop分支上的代码部署到QA/staging环境并进行严格测试。因此，使用GitFlow你从develop分支切出一个release分支，然后将release部署到所述staging环境。

首先，只想快速澄清一些事情：第一次特定项目/repo经历这个过程时，实际上您将从develop中分叉/创建此新release分支，是吗？以后所有其他时间，你只需将develop合并到release中，是吗？

然后QA在staging env上测试release分支，一切正常，我们准备好部署到prod了。你会:

• 部署到prod，然后合并release到master吗？ ; 还是
• 将release合并到master，然后部署到prod？

我问这个问题是因为在前一种情况下，似乎你需要将release分支部署到prod，然后再次部署到prod，然后合并到master。这听起来还好，但通常prod和非prod环境不相同，完美运行的代码在staging上运行时立即崩溃了。我知道GitFlow支持hotfix branches的概念，但它们仅限于小修复。在需要回滚/撤消发布的复杂修复情况下，我们现在将“脏代码”（某些原因导致prod破坏的代码）合并到master中。

在后一种情况下，如果你需要涉及IT/Ops进行产品发布，则从合并并提交生产环境发布请求到实际进行生产部署可能需要数小时甚至数天。在此期间，你有一个master分支，它说“功能X、Y和Z已经上线”，但事实上它们并没有。

我想知道GitFlow是否可以解决这个问题，或者已知的解决方案是什么。

- smeeb

Answer 1

我所在的项目非常混乱，决策可以在几分钟内发生改变，因此我的策略是尽可能推迟软件配置管理决策。

特别是合并到主分支：我们只有在生产环境部署成功并且确认邮件表明烟雾测试正常后才会合并到主分支。这样，我们通过管理决策变化、回退部署、技术问题或任何可能发生的问题来掌控混乱局面。

起初，我们在进入生产环境之前就合并到主分支，但技术问题、回滚、最后一刻的管理决策等问题给我们带来了很多麻烦，所以我们改变了策略，在过去的三年中一直运作良好。

如果最终在生产环境中发现了某些回归问题，那将成为一个热修复问题，必须像处理热修复问题一样处理 :)

- Luis

---

这种方法的问题在于，合并到主分支并打标签后，合并后的标签实际上指向与您用于部署的提交不同的提交。这会破坏可重复构建性。 - RaGe

抱歉，我没有理解您的意思。您能否详细说明一下？您所说的“合并后标签”是什么意思，其目的是什么？ - Luis

根据gitflow的规定，一旦你将一个发布分支合并到主分支中，就会在主分支中对其进行标记。请参见此处。在您的情况下，您的生产部署是从最后一个绿色提交（合并之前）开始的，而标记指向不同的青色提交。如果您想稍后重复完全相同的部署，则从标记部署无法工作，因为您正在从不同的提交中部署。 - RaGe

那么，您可以标记绿色提交。我认为这样做并不是什么大问题。最终，Git并不在乎分支，而在乎图形，因此我们处理的是提交图形。如果重要的是标记部署到生产环境中的更改，您只需要标记发送到生产环境的提交，无论分支如何。完成后，此提交可以合并到主分支，并且其余开发人员将主分支合并到各自的分支中。 - Luis

@BornToCode 一旦代码投入生产，就没有回头路了。这里的问题是，“拖延”决策，如果您尽可能地推迟合并到主分支，您将保持主分支的原始状态，避免在主分支上进行丑陋的还原或修补。 - Luis

Answer 2

您创建的发布分支是短暂的，类似于您创建的功能分支。完成发布后，您将删除该分支。例如，我会创建一个release/0.1.0分支，完成工作，然后合并。

在部署到生产环境时，我总是从主分支获取代码，也就是说，在部署之前，我会先将发布分支合并到主分支。

GitFlow 更多的是关于向前发展，而不是向后。这就是为什么要使用热修复来修复已识别的问题的原因。

就进入生产所需的时间而言，GitFlow 真的不太关注，并且我认为它不会在这方面提供太多帮助。无论使用哪种分支策略，这都将成为您的问题。

- Gary Ewan Park

---

不确定这是否应该是答案，我们缺少合并之前或之后发布的理由或利弊。 - NicolasW

在部署之前合并的一个巨大优势是很难错过最近合并到主分支中的任何错误修复（如果有的话），从而避免产生回归事故。因为这个原因，我认为这是最好的方法。 - NicolasW

我认为这是一个巨大的劣势。任何在旧版本中修复的热补丁并合并到主分支中，然后都会传播到任何发行候选版本和开发版本吧？否则，发行候选版本也将出现回归问题，因此将无法“发布”。你是说任何活跃的发布迭代都必须先合并到主分支才能获得那个热补丁，对吗？ - kevinmm

Answer 3

我想你实际上是从develop中创建/派生这个新的发布分支，是吗？

没错。首次操作时，您唯一的选择就是从主分支创建 release 分支，这将用于QA / Staging，以及之后部署到生产环境。

你在未来所有其他时间里都只需将 develop 合并到 release，是吗？

这得看情况。按照 Git Flow 的描述，发布分支是一个 短寿命 分支。它只能从 develop 派生，并合并到 master。理论上，在发布完成后，应将 release 合并回 develop，然后将其删除。您唯一需要合并到 release 中的是 hotfix。这是关于该流程的一篇良好且清晰的 文章。

这取决于不同的团队。我曾经在遵循GitFlow描述的团队中工作过，也有一些团队选择仅删除“release”并从develop重新创建它，就像第一次一样。

部署到生产环境，然后将发布分支合并到主分支？还是先将发布分支合并到主分支，然后再部署到生产环境？

理论上，主分支应始终包含可供生产使用的代码，唯一保证这一点的方法是部署到生产环境的内容与主分支完全相同。话虽如此，我们可能无法为你的团队提供完美的解决方案。

例如，我目前在一个CI / CD管道团队中工作，我们别无选择，只能在部署之前进行合并：自动从master进行部署。我见过一些发布间隔太长的团队，他们更愿意在部署之前使用“release”分支，然后再进行合并。这样可以避免在“release”->“master”合并期间产生人为错误（可能会积累多年的严重冲突）。

我认为你应该选择最适合你的解决方案，因为GitFlow可能无法涵盖每种可能的情景和上下文。

- r3gularJ0hn

Answer 4

对于小公司来说，从主分支(master)部署是可以的。但在需要支持多个版本的情况下，您应该维护并从发布分支(release branch)部署。

- Ken Netherland

Answer 5

我认为先部署再合并的原因是因为在CI/CD流水线中，您可以在部署后进行一些烟雾测试，如果事情不稳定，您可以通过仅部署最初的主分支来撤销，因为您的流水线失败了，那么合并到主分支将不会发生。

但是，如果您先合并再部署，那么回滚可能会很棘手，因为您必须回滚合并...所以我认为从发布中部署是有意义的，如果事情稳定，然后您将其合并到主分支。

- Malush

Answer 6

在我的以前的团队中，分支策略是创建一个发行版分支，在发行版分支上进行最终测试，然后在部署之前将发行版分支合并到主分支。然后使用主分支进行生产部署。

但是我的当前团队采用了一种不同的方法，即使用发行版分支部署到生产环境，并在成功的生产部署后将发行版分支合并到主分支。这种方法的好处在于确保代码在真实的生产环境中运行正常，这样我们就可以说代码已经在生产环境中正确运行，然后将发行版分支合并到主分支，这样主分支中的所有内容都在实际中运作。这种方法的另一个优点是如果部署出现问题，很容易回滚，只需使用主分支重新部署即可。

对于以前的方法，我有过回滚更改的经验，因为生产环境更加复杂，在部署之前没有在非生产环境中发现问题，因此我需要在主分支中进行变基/还原更改，这意味着主分支已经损坏，直到我进行变基/还原为止:(

我喜欢在发行版分支上发布内容，并在生产部署后将其合并回主分支，这样易于回滚，并通过在真实的生产环境中运行代码而确保主分支中的代码正确，而不仅仅是在非生产环境中。最终，这还取决于哪种方法适合您的项目/团队。

- wei