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

How should Git Flow work with QA testing both a release and a new feature?

提问by jowie

We are using Git Flow on our latest iOS project and I am trying to work out a way of working with QA so that they can test the latest release, as well as testing a new feature, without having to worry about which bugs were fixed in which branch.

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

At present, they have been testing on the release/v1.0.1branch, which has several bugs fixed from the original release/v1.0. Concurrently, I have been working on a new feature which has been planned for the v1.1 release, but was branched off from the developbranch at the same time as release/v1.0.1and therefore has none of the bug fixes in it.

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

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!

今天，QA 部门想对我的新功能进行试驾。但是，如果我从我的分支创建它们，则它们重新测试和关闭的错误修复都不会在那里。因此，我会收到大量关于重新引入的错误的抱怨和恐慌......我想避免这种情况！

So, what is the best way to get them to test this? I could merge release/v1.0.1into my feature branch, but then I should make sure I don't merge back into developbefore release/v1.0.1has been released… And I guess to a certain extent, this breaks the Git Flow methodology. I could create a completely new branch just for QA testing, which merges my feature with release/v1.0.1, but then what do I do with any bugs they find on this branch? Where do I merge it back into after the round of QA?

那么，让他们对此进行测试的最佳方法是什么？我可以合并release/v1.0.1到我的特性分支，但是我应该确保在发布develop之前我不会合并回release/v1.0.1......而且我想在某种程度上，这打破了 Git Flow 方法论。我可以为 QA 测试创建一个全新的分支，它将我的功能与release/v1.0.1. 经过一轮 QA 后，我应该将其合并回哪里？

On top of all of this, I have to consider the build numbers and version numbers, so that they make sense. Currently, version numbers are the ones used for release, and build numbers are incremented with each new build for QA. However, if they are receiving builds from two separate branches, I could end up with build number clashes which would cause confusion.

最重要的是，我必须考虑内部版本号和版本号，以便它们有意义。目前，版本号是用于发布的，版本号随着每个新版本的 QA 增加而增加。但是，如果他们从两个独立的分支接收构建，我最终可能会出现构建号冲突，这会导致混淆。

What would be the best way of dealing with these problems?

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

回答by jub0bs

I'll refer to parts of the first diagram from nvie.com's Git Flow pagethroughout my answer; for completion, I've added a screenshot of it below.

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

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.1into my feature branch, but then I should make sure I don't merge back into develop before release/v1.0.1 has been released`...

今天，QA 部门想对我的新功能进行试驾。但是，如果我从我的分支创建它们，则它们重新测试和关闭的错误修复都不会在那里。因此，我会收到大量关于重新引入的错误的抱怨和恐慌......我想避免这种情况！

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

No; you should not merge a release branch directly into a feature branch. According to the Git Flow model, you should (continually)

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

1. merge release/v.1.0.1into the developbranch,
2. merge developinto your feature branch(es),

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

in order to bring stabilizing changes from release/v.1.0.1into the your feature branch(es).

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

(Unfortunately, the image above doesn't show continual merges of developinto feature, but that's what you're supposed to do.)

（不幸的是，上图没有显示developinto 的连续合并feature，但这就是您应该做的。）

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

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

There is some ambiguity, there. Are you suggesting merging featureinto release/v1.0.1, or merging release/v1.0.1into feature? You shouldn't do the former, because it's too late for the new features to go into release/v.1.0.1; they'll have to ship with a future release, i.e. afterv1.0.1. Read the bubble on the left:

有一些歧义，那里。您是建议合并feature到release/v1.0.1还是合并release/v1.0.1到feature？你不应该做前者，因为新特性已经太晚了release/v.1.0.1；他们必须随未来版本一起提供，即在v1.0.1. 阅读左边的气泡：

And you shouldn't do the latter either; at least, not directly. As explained above, in order to bring changes from release/v1.0.1into feature, you should first merge release/v1.0.1into develop, and then merge developinto feature; this can/should happen multiple times before featureis ready to be merged back into develop.

你也不应该做后者；至少，不是直接的。如上所述，为了从release/v1.0.1into带来变化feature，您应该先合并release/v1.0.1到develop，然后再合并develop到feature；在feature准备好合并回develop.

---

---

Addendum

附录

If you follow the Git Flow model to the letter,

如果你完全遵循 Git Flow 模型，

1. you shouldn't have two or more coexisting release branches, and
2. QA should only ever test release (a.k.a. stabilizing) branches.

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

Therefore, if other features are supposed to go into v1.1, you can't ask QA to review your new features yet; you have to wait until the other features are completed. Once all the features for v1.1have been completed and integrated into develop, create a release/v1.1branch (that stems from the head of develop); then ask QA to start testing/stabilizing that branch.

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

If, on the other hand, you really can't wait for the other features to be completed before asking QA to test your own new features, you should create an intermediate release branch (called v1.0.2, I guess) stemming from developand tell QA to test release/v1.0.2. Once it's been stabilized to a satisfactory extent, merge it into master(and into develop).

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