Git Flow 应该如何与 QA 一起测试版本和新功能？

Posted 2023-02-19

【中文标题】Git Flow 应该如何与 QA 一起测试版本和新功能？

【英文标题】：How should Git Flow work with QA testing both a release and a new feature?

【发布时间】：2014-10-04 00:28:42

【问题描述】：

我们正在我们最新的 ios 项目中使用 Git Flow，我正在尝试找出一种与 QA 合作的方式，以便他们可以测试最新版本以及测试新功能，而不必担心哪些错误固定在哪个分支。

目前，他们已经在release/v1.0.1 分支上进行测试，该分支修复了原始release/v1.0 的几个错误。同时，我一直在开发一个计划用于 v1.1 版本的新功能，但它与release/v1.0.1 同时从develop 分支分支出来，因此其中没有任何错误修复。

今天，QA 部门想试用我的新功能。但是，如果我从我的分支创建它们，它们已经重新测试和关闭的错误修复都不会在那里。因此，我会收到大量关于重新引入的错误的投诉和恐慌......我想避免这些！

那么，让他们进行测试的最佳方法是什么？我可以将release/v1.0.1 合并到我的功能分支中，但是我应该确保在release/v1.0.1 发布之前我不会合并回develop……而且我想在某种程度上，这破坏了Git Flow 方法。我可以为 QA 测试创建一个全新的分支，将我的功能与release/v1.0.1 合并，但是我该如何处理他们在这个分支上发现的任何错误？在一轮 QA 之后，我应该将其合并回哪里？

除此之外，我还必须考虑内部版本号和版本号，以便它们有意义。目前，版本号是用于发布的版本号，并且内部版本号随着质量检查的每个新版本而增加。但是，如果他们从两个不同的分支接收构建，我最终可能会遇到构建号冲突，这会导致混淆。

处理这些问题的最佳方法是什么？

【问题讨论】：

事实证明，我们希望让 QA 先完成对 1.0.1 的测试，这意味着我们可以将其重新合并以开发并创建具有新功能的新 1.1 版本他们进行测试...但是，在 Git Flow 和 QA 工作流程方面，了解其他人是否有同样的困境仍然非常有用。

master 合并到发布准备就绪时，根据the git flow protocol。我没有在我的流程中提到master，因为release/v1.0.1 还没有完成，所以还没有准备好合并回master 或develop。

我会将release/v1.0.1 合并到master 中，当它被 QA 批准后，但目前该分支上还有一些错误需要解决。

您不必等到release/v1.0.1 没有错误后再将其合并回develop。如果您查看nvie.com page 上的第一个图表，您会看到一个气泡，上面写着“来自rel. branch 的错误修复可能会不断合并回develop”。

它在哪里说我们应该不断地将开发合并到我们的功能分支@Jubobs？我在下面的答案中看到开发中发生的几件事，没有合并到功能分支。将开发合并到您的功能中是否存在好/坏或正确/错误的时间？

【参考方案1】：

我将在整个回答过程中参考nvie.com's Git Flow page 中第一张图表的部分内容；为了完成，我在下面添加了它的屏幕截图。

今天，QA 部门想试用我的新功能。但是，如果我从我的分支创建它们，它们已经重新测试和关闭的错误修复都不会在那里。因此，我会收到大量关于重新引入的错误的投诉和恐慌......我想避免这些！

那么，让他们进行测试的最佳方法是什么？我可以将release/v1.0.1 合并到我的功能分支中，但是我应该确保在发布/v1.0.1 发布之前我不会合并回开发中`...

没有；您不应该将发布分支直接合并到功能分支中。根据 Git Flow 模型，您应该（持续地）

将release/v.1.0.1 合并到develop 分支中， 将develop 合并到您的功能分支中，

为了将来自 release/v.1.0.1 的稳定更改引入您的功能分支。

（不幸的是，上图没有显示develop 不断合并到feature，但这是你应该做的。）

我可以为 QA 测试创建一个全新的分支，它将我的功能与 release/v1.0.1 [...] 合并

这里有些模棱两可。您是建议将feature 合并到release/v1.0.1，还是将release/v1.0.1 合并到feature？你不应该做前者，因为新功能进入release/v.1.0.1已经太晚了；他们必须在未来的版本中发布，即之后 v1.0.1。阅读左边的气泡：

你也不应该做后者；至少，不是直接的。如上所述，为了将release/v1.0.1的更改带入feature，您应该首先将release/v1.0.1合并为develop，然后将develop合并为feature；在 feature 准备好合并回 develop 之前，这可以/应该发生多次。

---

附录

如果您严格遵守 Git Flow 模型，

您不应该有两个或更多并存的发布分支，并且 QA 只应测试发布（又名稳定）分支。

因此，如果其他功能应该进入v1.1，您还不能要求 QA 审核您的新功能；您必须等到其他功能完成。一旦v1.1 的所有功能都完成并集成到develop 中，创建一个release/v1.1 分支（源于develop 的头部）；然后要求 QA 开始测试/稳定该分支。

另一方面，如果在要求 QA 测试您自己的新功能之前，您真的不能等待其他功能完成，您应该创建一个中间发布分支（我猜叫 v1.0.2）来自develop 并告诉QA 测试release/v1.0.2。一旦稳定到令人满意的程度，将其合并到master（和develop）中。

【讨论】：

非常具有描述性和信息性，谢谢。您对如何让他们对新功能进行适当的测试有什么建议吗？我不喜欢从develop 分支为他们提供构建，但正在考虑创建第二个发布分支供他们测试，例如release/v1.1。 SourceTree 中的 Git Flow 不允许同时发布两个分支，但我看不出它有什么具体问题……？

至于你刚才指出的模棱两可的地方，我想我的意思是我会从release/v1.0.1 创建一个类似qa 的分支，然后将我的功能分支合并到qa 中。现在这并不重要，因为这些功能今天完成并合并回develop。我现在还按照您的建议将所有错误修复从release/v1.0.1 合并到develop。现在我只需要知道 QA 如何最好地测试下一个版本的新功能。我应该创建一个release/v1.1 吗？不过，可能还有更多功能需要添加。

好的，谢谢。我猜 Git Flow 只是为线性测试工作流设计的，这是明智的。不幸的是，将其融入我的现实世界场景并不容易，但我可能会按照您建议的方式创建一个中间发布分支。无论如何，拥有两个发布分支会与内部版本号混淆！

我们总是（我认为应该总是）在合并回开发之前对特性分支进行测试，以便可以权衡修复出现的新错误的成本与特性的价值（所以它不会阻止发布。）虽然我们在 QA 之前从开发合并到功能，但在高流量时期，经常会有其他功能进入，我们已经发现了一些不重要的问题测试后合并。除了对开发中的每个功能进行第二轮完整的 QA 之外，我想不出一个强大的解决方案，我想知道其他人如何处理这个问题。

@JoshuaGoldberg，这个评论本身就是一个很好的 SO 问题，因为这个帖子现在已经快一年了。