在git流模型中，我应该从主版本中的合并提交构建到发布版本吗？

在我的公司，我们有一个CI/构建服务器，用于测试和构建版本（以及功能和开发分支）。 在分支模型中，当您需要发布分支时，请开发分支并将其命名为（例如）release-1.4。然后，CI/Build服务器将自动构建分支，我们将它部署到一个临时服务器上进行手动集成测试。一旦我们对构建感到满意，我们就会部署它。但是在git流分支模型中，我们需要首先合并到master和tag。问题是，我们是否需要在这次合并之后运行另一个构建和测试周期，或者什么

合并和标记的结果是标记指向与发布版本不同的（技术上）提交，这似乎很奇怪。在我们进入master之后重新构建似乎也很糟糕，因为我们会觉得必须测试这个构建，以确保它也正常

我提出的选项有：

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

问题是，我们是否需要在这次合并之后运行另一个构建和测试周期，或者什么

该合并不应该破坏任何东西，因为它应该是一个快进合并，主服务器上的所有提交都在发布分支上。因此，您不能在发布分支之外的主发布合并上创建错误

因此，从技术上讲，这不是您构建的精确承诺，但其理念是，主分支上的所有内容都在生产中。在任何时候，如果有人拉主分支，他应该得到当前的生产代码。这就是为什么您不合并，然后构建、测试、等待，并在master上修复发布的内容

---

现在事情并不总是一帆风顺。当版本经过验证并准备发布时，您可能已经遇到了需要热修复的主要生产缺陷，在这种情况下，一些提交已推送到master和developer，但没有推送到发布分支。如果发生这种情况，我会在develope上重新设置发布分支的基础（在团队中工作时要小心，合并更安全），然后重新构建。总之，如果在创建发布分支和验证它之间没有热修复程序，则无需重建。

如果合并到主分支不是快进的，则意味着可能会产生新的未测试代码。即使是完全明显的自动合并也可能导致无法编译的代码。因此，如果出于某种原因它不是ff合并，您需要进行测试。否则，它就是同一个提交。

master不会被快速转发到该提交吗？因为通常情况下，发布中的所有提交都会合并到开发中，所以之前的主提交也会合并；通过归纳，它将是ff合并到主分支中的第一个提交。