12

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

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

我想出的选项是：

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

2 回答 2

8

问题是，我们是否需要在合并后运行另一个构建和测试周期？

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

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

现在事情并不总是一帆风顺。当版本已经过验证并准备好发布时，您可能会遇到需要修补程序的主要生产错误，在这种情况下，一些提交已被推送到 master 和 development，但没有推送到发布分支。如果发生这种情况，我会重新设置（在团队中工作时要小心，合并更安全）开发上的发布分支（以赶上修补程序）并再次重建。综上所述，如果在发布分支创建和验证之间没有修补程序，则无需重新构建。

于 2013-11-06T22:01:54.010 回答
0

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

于 2013-11-06T22:04:38.863 回答