title: How should Git Flow work with QA testing both a release and a new feature?
body: <p>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.</p>
  <p>At present, they have been testing on the <code>release/v1.0.1</code> branch, which has several bugs fixed from the original <code>release/v1.0</code>. Concurrently, I have been working on a new feature which has been planned for the v1.1 release, but was branched off from the <code>develop</code> branch at the same time as <code>release/v1.0.1</code> and therefore has none of the bug fixes in it.</p>
  <p>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!</p>
  <p>So, what is the best way to get them to test this? I could merge <code>release/v1.0.1</code> into my feature branch, but then I should make sure I don't merge back into <code>develop</code> before <code>release/v1.0.1</code> 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 <code>release/v1.0.1</code>, 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?</p>
  <p>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.</p>
  <p>How can I deal with these problems?</p>