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

Question

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

发布分支听起来像是在发布之前运行所有回归测试的地方。然而，发布分支然后合并到主标记中，并且这是最终发布到生产中的。如果有从发布分支到主控的合并冲突，会发生什么？听起来像主人需要完全重新测试（这可能是昂贵的）。即使没有冲突，将合并推向生产是否安全，还是需要进行额外的基本烟雾测试？

Answer 1

仔细追踪GitFlow图表后，我确信自己应该有永不当合并到主（即如果严格遵循过程）任何冲突。究其原因，是因为时间表的：

1. 开发分支，从主创建
2. 特点致力于在开发分支
3. 发布分支创建（包括所有从开发至今提交）
4. 发布分支中的错误已修复
5. 准备好后，发布分支合并到主发行版
6. 主发行版必须包含来自Develop + Release分支的所有提交。冲突不应该发生，因为在开发分支创建之后，Master上没有做任何事情（这是冲突发生的唯一方式）。此外，此时的代码应该与Release分支上的最新提交相同，这意味着不需要额外的测试。

我简化了GitFlow图说服这个自己：回答

Answer 2

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

根据您的产品是什么以及如何推出它，实际测试可能会发生变化。我们有几台生产服务器，我们部署了新版本的代码。这些服务器已经过彻底测试，但我们的客户无法访问。当那些退出时，我们将它们与其余的生产服务器交换出去。重复部署和测试。一切通过后，所有的生产服务器都被放回到面向客户的服务器的实时池中。

如果发生故障，我们以相同的方式回滚。