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