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

git testing branching-and-merging qa git-flow
jowie picture jowie · Aug 11, 2014 · Viewed 16.2k times · Source

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?

Answer

jub0bs picture jub0bs · Aug 11, 2014

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.

enter image description here

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

enter image description here

(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:

enter image description here

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

Related questions

Git branching strategy integated with testing/QA process

Our development team has been using the GitFlow branching strategy and it has been great ! Recently we recruited a couple testers to improve our software quality. The idea is that every feature should be tested/QA by a tester. In …

Read More
How do I undo the most recent local commits in Git?

I accidentally committed the wrong files to Git, but didn't push the commit to the server yet. How can I undo those commits from the local repository?

Read More
How do I delete a Git branch locally and remotely?

I want to delete a branch both locally and remotely. Failed Attempts to Delete a Remote Branch $ git branch -d remotes/origin/bugfix error: branch 'remotes/origin/bugfix' not found. $ git branch -d origin/bugfix error: branch 'origin/bugfix' not …

Read More