在我的公司，我们有一个CI / Build服务器，用于测试和构建版本（以及功能和开发分支）。 在git flow分支模型中，当它是时候释放你分支开发并命名它（例如）release-1.4。然后，CI / Build服务器将自动构建分支，我们将其部署到临时服务器以进行手动集成测试。一旦我们对构建感到满意，我们就想部署它。但是在git flow分支模型中，我们需要首先合并到master和tag。问题是，在合并之后我们还需要运行另一个构建和测试周期吗？
合并和标记结尾似乎很奇怪，标签指向与发布版本不同的（技术上）提交。在我们进入主人之后重建似乎也很糟糕，因为我们会觉得有必要测试那个版本以确保它也没问题。
我提出的选项是：
答案 0 :(得分：7)
问题是，我们是否需要在此合并后运行另一个构建和测试周期或什么？
该合并不应该破坏任何东西，因为它应该是快进合并，master上的所有提交都在发布分支上。因此，您无法在发布后分支上创建主合并后的错误。
技术上是的，这不是你构建的精确提交，但理念是主分支上的所有内容都在生产中。在任何时候，如果有人拉动主分支，他应该获得当前的生产代码。这就是为什么你不合并然后构建，测试，等待，并修复master上的东西以进行发布。
现在事情并不总是顺利进行。当发布已经过验证并准备发布时，您可能遇到需要修补程序的主要生产错误，在这种情况下，某些提交已被推送到掌握和开发但不是发布分支。如果发生这种情况，我会重新定义（在团队工作时要小心，合并更安全）发布分支（以便赶上修补程序）并重新重建。总而言之，如果创建发布分支的时间和验证时间之间没有修补程序，则无需重建。
答案 1 :(得分：0)
如果您合并到主分支不是快进，则意味着它可能导致新的未经测试的代码。即使是完全明显的自动合并也会导致代码无法编译。所以，如果由于某种原因它不是ff合并，你需要测试。否则，它是相同的提交。