Git Flow如何与QA一起测试版本和新功能？ [英] How should Git Flow work with QA testing both a release and a new feature?

问题描述

我们在我们最新的iOS项目上使用Git Flow，并试图找出一种与QA合作的方式，以便他们可以测试最新版本以及测试新功能，而无需担心哪些bug分别固定在哪个分支上。

目前，他们已经在 release / v1.0.1 分支上进行了测试，其中有几个bug是从原来的 release / v1.0 修复的。同时，我一直致力于为v1.1发行版计划的新功能，但是在 develop 分支中分支，同时 release / v1.0.1 ，因此没有任何bug修正。

今天，QA部门想要我的新功能用于试驾。但是，如果我从我的分支创建它们的构建版本，则它们中没有重新测试和关闭的错误修复程序将在其中。因此，我将收到大量的抱怨和恐慌，这些错误已经被重新引入......我想避免这种情况！

那么，获取它们的最佳方式是什么？测试这个？我可以将 release / v1.0.1 合并到我的特性分支中，但是我应该确保我不会合并回到 develop release / v1.0.1 之前的$ c>已经发布了......我想在某种程度上，这打破了Git Flow方法。我可以为QA测试创建一个全新的分支，它将我的特性与 release / v1.0.1 合并，但是我该如何处理在这个分支上发现的任何错误？在这一轮QA之后，我应该在哪里合并它？

除此之外，我必须考虑内部版本号和版本号，以便它们能够感。目前，版本号是用于发布的版本号，并且每个新版本的质量保证都会增加内部版本号。但是，如果他们从两个不同的分支获得构建，我最终可能会发生构建编号冲突，这会造成混淆。

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

解决方案

我会参考 nvie.com的Git Flow页面;为了完成，我在下面添加了一个截图。

今天，QA部门希望将我的新功能用于试驾。但是，如果我从我的分支创建它们的构建版本，则它们中没有重新测试和关闭的错误修复程序将在其中。因此，我将收到大量的抱怨和恐慌，这些错误已经被重新引入......我想避免这种情况！

那么，获取它们的最佳方式是什么测试这个？我可以将 release / v1.0.1 合并到我的特性分支中，但是我应该确保在release / v1.0.1发布之前我不会合并到开发中。 ...

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

1. 合并 release / v.1.0.1 code>放入开发分支，

2. 合并开发您的功能分支



，以便从 release / v.1.0.1带来稳定的更改放入您的功能分行。

（不幸的是，上面的图片并没有显示 develop
lockquote
特性，但这就是你应该做的事情。）

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

合并

这里有一些不明确的地方。您是否建议将 feature 合并到 release / v1.0.1 中，或合并 release / v1。 0.1 转换为功能？你不应该这样做，因为新特性进入 release / v.1.0.1 ;为时已晚。他们将不得不发布未来版本，即在 v1.0.1 之后的。阅读左侧的泡泡：

你也不应该这样做;至少不是直接的。如上所述，为了将变化从 release / v1.0.1 变为特性，您应该先将 release / v1.0.1 转换为 develop ，然后合并 develop 到特征;这可以/应该在特性准备合并回 develop 。

$ b之前发生多次
$ b

---

附录

如果您遵循Git Flow模型，

1. 您不应该有两个或更多共存的发布分支，并且
   
2. QA只应该测试版本aka stabilizing ）branches。

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

另一方面，如果您在询问QA之前是否真的不能等待其他功能完成测试你自己的新功能，你应该创建一个从开发的中间发布分支（我称之为 v1.0.2 >并告诉QA测试 release / v1.0.2 。将它合并到 master （并放入 develop ）。

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.

At present, they have been testing on the release/v1.0.1 branch, 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 develop branch at the same time as release/v1.0.1 and therefore has none of the bug fixes in it.

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… 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?

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.

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

解决方案

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

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`...

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

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

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

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

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

There is some ambiguity, there. Are you suggesting merging feature into release/v1.0.1, or merging release/v1.0.1 into 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. after v1.0.1. Read the bubble on the left:

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

---

Addendum

If you follow the Git Flow model to the letter,

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

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.1 have been completed and integrated into develop, create a release/v1.1 branch (that stems from the head of develop); then ask QA to start testing/stabilizing that branch.

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 develop and tell QA to test release/v1.0.2. Once it's been stabilized to a satisfactory extent, merge it into master (and into develop).

这篇关于Git Flow如何与QA一起测试版本和新功能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！