我一直在 git 中寻找一个好的分支模型，发现 GitFlow 非常适合我们的开发环境。但是，一个悬而未决的问题是如何以及在何处测试我们的版本。
发布分支听起来像是在发布之前运行所有回归测试的地方。然而，发布分支随后被合并到 master 中，并被标记，这就是最终投入生产的东西。如果从发布分支到主分支存在合并冲突怎么办？听起来 master 需要完全重新测试（这可能会很昂贵）。即使没有冲突，将合并推送到生产环境是否安全，还是需要运行额外的基本冒烟测试？
【问题讨论】：
仔细跟踪GitFlow图后，我说服自己永远不要在合并到master时（即严格按照流程）发生冲突。原因，是因为时间线：
我简化了 GitFlow 图来说服自己：
【讨论】：
我认为应该在发布的每个阶段都进行测试。创建一个轻量级的发布测试子集，您可以直接针对生产环境运行这些测试，以至少测试基本功能。当然，不要对生产进行加载/性能测试。
根据您的产品是什么以及您推出产品的方式，实际测试可能会发生变化。我们有一些生产服务器，我们在其中部署了新的发布代码。这些服务器经过彻底测试，但我们的客户无法访问。当这些检查出来时，我们将它们与我们的其他生产服务器交换。重复部署和测试。一切都结束后，所有生产服务器都被放回面向客户的服务器的实时池中。
如果发生故障，我们会以几乎相同的方式回滚。
【讨论】：