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

Question

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 featu

Answer 1

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