在Git Flow模型中，我应该从主分支的合并提交构建到发布吗？

Question

在我们公司，我们有一个CI/Build服务器，用于测试和构建发布版本（以及功能和开发分支）。 在git flow分支模型中，当需要发布时，您会从develop分支中分叉并命名它（例如release-1.4）。然后，CI/Build服务器将自动构建该分支，我们将其部署到暂存服务器进行手动集成测试。一旦我们对生成的结果满意，我们就可以进行部署。但是，在git flow分支模型中，我们需要首先合并请求和标记master分支。问题是，在此合并之后，我们是否需要进行另一轮构建和测试周期呢？

合并和标记后指向的标签与实际构建版本不同似乎很奇怪。重新构建也似乎不好，因为这样我们会觉得有必要测试那个构建版本是否可靠。

我的选择是：

• 在发布分支中构建，然后合并、重建和测试主分支
• 在发布分支中构建和测试，然后合并并相信不需要新的构建
• 修改git flow模型，删除合并到主分支的步骤，只需标记我们想要发布的发布分支中的最终提交。
  • 不合并到主分支会失去什么？
  • 在这种情况下，我们可能可以直接在主分支上开发

- thephred

---

难道主分支不会被快进到那个提交吗？因为通常，发布中的所有提交都会合并到开发分支中，所以之前的主分支提交也会被合并；通过归纳法，它将被快进合并到主分支中的第一个提交。 - Max Yankov

Answer 1

问题是，我们需要在此合并之后再次运行构建和测试循环吗？

那个合并不应该破坏任何东西，因为它应该是快速向前合并，master上的所有提交都在release分支上。因此，在合并后不能在master上创建没有在release分支上的错误。

所以从技术上讲，确实不是构建的精确提交，但哲学是，主分支上的所有内容都处于生产状态。随时，如果有人拉取主分支，他应该得到当前的生产代码。这就是为什么你不要在发布之前合并，然后构建、测试、等待，并在主分支上修复问题。

现在情况并不总是顺利的。在经过验证并准备好发货的时候，您可能会遇到需要热修复的重大生产错误，在这种情况下，一些提交已经被推送到主分支和开发分支，但没有推送到发布分支。如果发生这种情况，我会将发布分支基于开发分支进行重新贴标签（在团队中工作时要小心，合并更安全），然后再次进行构建。总之，如果在创建发布分支和验证它之间没有热修复，就不需要重新构建。

- Joucks

Answer 2

如果您的合并到主分支不是快进合并，那么它可能会导致新的、未经测试的代码。即使是完全明显和自动化的合并也可能导致代码无法编译。因此，如果由于某种原因它不是快进合并，您需要进行测试。否则，它就是相同的提交。

- Max Yankov