Git Flow如何使用QA测试版本和新功能？

Question

我们在最新的iOS项目中使用Git Flow，我正在尝试使用QA的方式，以便他们可以测试最新版本，以及测试新功能，而无需担心哪些错误固定在哪个分支。

目前，他们一直在release/v1.0.1分支上进行测试，该分支有一些错误，原来是release/v1.0。同时，我一直致力于为v1.1发布计划的新功能，但是在develop的同时从release/v1.0.1分支分支，因此没有任何错误修复它。

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

那么，让他们测试这个的最佳方法是什么？我可以将release/v1.0.1合并到我的功能分支中，但是我应该确保在develop发布之前我不会合并回release/v1.0.1 ...我想在一定程度上，这打破了Git Flow方法论。我可以创建一个全新的分支，仅用于QA测试，它将我的功能与release/v1.0.1合并，但是我如何处理他们在这个分支上找到的任何错误？在QA轮次之后我将它合并到哪里？

除此之外，我还要考虑构建号和版本号，以便它们有意义。目前，版本号是用于发布的版本号，并且构建号随着QA的每个新构建而递增。但是，如果他们从两个独立的分支接收构建，我最终可能会发生构建数字冲突，这会引起混淆。

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

Answer 1

在我的回答中，我将从nvie.com's Git Flow page引用第一张图的部分内容;为了完成，我在下面添加了它的截图。

  

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

     

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

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

1. 将release/v.1.0.1合并到develop分支
2. 将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模型，那么

1. 您不应该有两个或更多共存的发布分支，
2. QA应该只测试发布（a.k.a. 稳定）分支。

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

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