GitFlow：正确测试发布分支和主分支

Question

我一直在寻找一个好的git分支模型，发现GitFlow非常适合我们的开发环境。然而，一个突出的问题是如何以及在哪里测试我们的发布版本。

发布分支听起来像是在发布之前运行所有回归测试的地方。然而，发布分支随后被合并到主分支中，并被标记为最终要发布到生产环境的版本。如果从发布分支到主分支存在合并冲突，会发生什么？看起来需要完全重新测试主分支（这可能很耗费时间）。即使没有冲突，将该合并推送到生产环境是否安全，或者是否需要运行额外的基本烟雾测试？

- yura

Answer 1

在仔细追踪GitFlow图之后，我确信如果严格按照此过程进行，则合并到主分支时永远不应该出现任何冲突。原因是由于时间轴：

1. 从主分支创建开发分支
2. 在开发分支上提交功能
3. 创建发布分支（其中包括到目前为止从开发分支提交的所有内容）
4. 在发布分支中修复错误
5. 准备就绪后，将发布分支合并到主分支
6. 主分支必须包含来自开发和发布分支的所有提交。冲突不应发生，因为在创建开发分支后没有在主分支上进行任何操作（这是唯一可能导致冲突的方式）。此外，此时的代码应与发布分支上最新提交的代码相同，这意味着无需进行额外的测试。

我简化了GitFlow图以使自己相信这一点：

- yura

---

你的发布分支是否持久存在？ - m1nkeh

查看GitFlow: https://nvie.com/posts/a-successful-git-branching-model/ 基本上，如果你遵循这个模型，你就不需要保留你的发布分支。但这取决于你。 - yura

读一百遍，它就会有意义了。我正在尝试将其应用于自动化发布，为此通常需要一些连续的分支进行构建，这就是我提出问题的原因 :) - m1nkeh

我明白了。在我看来，保留发布分支没有任何伤害。 - yura

确实，这可能是我目前正在处理的问题的解决方案。将最新批准的构建 QA 构建合并到发布分支上，然后在 UAT 上触发新的构建，然后可以在那里稳定下来。最后，当准备好时，合并到主分支，这将触发另一个构建并部署到生产环境。 - m1nkeh

Answer 2

我认为在每个发布阶段都应该进行测试。创建一个轻量级的发布测试子集，可以直接针对生产环境运行以至少测试基本功能。当然不要在生产环境下进行负载/性能测试。

根据您的产品类型和推出方式，实际测试可能会有所不同。我们有几台生产服务器，我们将新版本代码部署到这些服务器上。这些服务器经过了彻底的测试，但客户无法访问。当这些检查通过后，我们将它们与其他生产服务器交换。然后重复部署和测试。在一切都通过之后，所有生产服务器都放回我们面向客户的服务器池中。

如果发生故障，我们会以类似的方式回滚。

- SWPhantom

---

感谢@SWPhantom的回答。你的回答对于Web应用程序是有意义的，并且对于你的用例是正确的。我应该在我的问题上更加清晰明了。我正在开发一个移动应用程序，因此我们实际上没有单独的dev/qa/perf/prod环境。此外，这个问题更多地涉及到在git-flow中如何处理发布和主分支，以便进行测试并准备好进行生产发布构建。 - yura