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的Git Flow页面参考第一张图的部分内容; 为了完成,我在下面添加了它的截图.

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

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

没有; 您不应将发布分支直接合并到功能分支中.根据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应该只测试释放(也就是稳定)分支.

因此,如果应该考虑其他功能v1.1,您不能要求QA审核您的新功能; 你必须等到其他功能完成.v1.1完成所有功能并将其集成后develop,创建一个release/v1.1分支(源自头部develop); 然后要求QA开始测试/稳定该分支.

如果,另一方面,你真的不能等待其他功能要求QA测试自己的新功能之前,必须完成,您应该创建一个中间版本分支(所谓的v1.0.2,我猜)从制止develop,并告诉QA测试release/v1.0.2.一旦它稳定到一个令人满意的程度,将其合并到master(并进入develop).