git - Git Flow 应该如何与 QA 一起测试发布和新功能？

Question

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

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

今天，QA 部门。想试用我的新功能。但是，如果我从我的分支为他们创建一个构建，他们重新测试和关闭的错误修复都不会在那里。因此，我将收到大量关于重新引入的错误的投诉和 panic ......我想避免!

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

除此之外，我还必须考虑内部版本号和版本号，以便它们有意义。目前，版本号是用于发布的版本号，构建号随着每个新构建的 QA 递增。但是，如果他们从两个独立的分支接收构建，我最终可能会遇到构建号冲突，这会导致困惑。

我该如何处理这些问题？

Answer 1

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

Today, the QA dept would like to take my new feature for a test drive. However, if I create them a build from my branch, none of the bug fixes they have retested and closed will be in there. I will therefore receive a deluge of complaints and panics about bugs that have been reintroduced... Which I want to avoid!

So, what is the best way to get them to test this? I could merge release/v1.0.1 into my feature branch, but then I should make sure I don't merge back into develop before release/v1.0.1 has been released`...

没有；您不应该将发布分支直接 merge 到功能分支中。根据 Git Flow 模型，你应该(持续)

1. merge release/v.1.0.1到develop分支，
2. 将 develop merge 到您的功能分支中，

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

(不幸的是，上图没有显示将 develop 连续 merge 到 feature 中，但这是您应该做的。)

I could create a completely new branch just for QA testing, which merges my feature with release/v1.0.1 [...]

这里有些歧义。您是建议将 feature merge 到 release/v1.0.1 中，还是将 release/v1.0.1 merge 到 feature 中？你不应该做前者，因为新功能进入 release/v.1.0.1 已经太晚了；他们必须随 future 版本一起发布，即之后 v1.0.1。阅读左侧的气泡:

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

---

附录

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

1. 你不应该有两个或更多共存的发布分支，并且
2. QA 应该只测试发布(又名稳定)分支。

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

另一方面，如果您真的等不及其他功能完成后再要求 QA 测试您自己的新功能，您应该创建一个中间发布分支(称为 v1.0.2，我猜)源于 develop 并告诉 QA 测试 release/v1.0.2。一旦稳定到令人满意的程度，将其 merge 到 master(并 merge 到 develop)。