31

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.

How can I deal with these problems?

Daniel Widdis
  • 8,424
  • 13
  • 41
  • 63
jowie
  • 8,028
  • 8
  • 55
  • 94
  • As it turns out, we're hoping to get QA to finish testing 1.0.1 first, which will mean that we can merge it back to develop and create a new 1.1 release with the new features for them to test... But it would still be very useful to find out if others have the same dilemma when it comes to Git Flow and QA workflow. – jowie Aug 11 '14 at 09:41
  • `master` is merged to when a release is ready, as per [the git flow protocol](http://nvie.com/posts/a-successful-git-branching-model/). I have not mentioned `master` in my flow, since `release/v1.0.1` is not yet finished, and so is not ready to be merged back into either `master` or `develop`. – jowie Aug 11 '14 at 14:52
  • I will merge `release/v1.0.1` into `master` when it has been approved by QA, but currently there are a few bugs left to resolve on that branch. – jowie Aug 11 '14 at 14:53
  • 2
    You don't have to wait until `release/v1.0.1` is bug-free before merging it back into `develop`. If you look at the first diagram on the [nvie.com page](http://nvie.com/posts/a-successful-git-branching-model/), you'll see a bubble that reads "Bugfixes from `rel. branch` may be continually merged back into `develop`". – jub0bs Aug 11 '14 at 14:59
  • You will still have to merge the finalised `release/v1.0.1` into `develop` *after* QA approves it, but, before that happens, you're supposed to continually merge the former into the latter as you go. – jub0bs Aug 11 '14 at 15:05
  • You're also supposed to continually merge `develop` into your feature branch (or, possibly, rebase your feature branch onto `develop`, in case you haven't shared your feature branch yet), in order to keep up to date with the latter. – jub0bs Aug 11 '14 at 15:09
  • That's very useful information, thanks. I was seriously considering merging the release changes to `develop`, but was unsure if it would break the Git Flow model… I hadn't seen that part of the diagram. :) – jowie Aug 11 '14 at 15:48
  • Related; https://stackoverflow.com/questions/18371741/git-branching-strategy-integated-with-testing-qa-process – Joshua Goldberg Apr 10 '15 at 17:03
  • 1
    Where does it say that we should be continually merging develop into our feature branches @Jubobs? I see several things happening in develop with no merge to the feature branch in your answer below. Is there a good/bad or right/wrong time to merge develop into your feature? – EMuentes Jan 11 '16 at 17:40

1 Answers1

27

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

Community
  • 1
  • 1
jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • 1
    Very descriptive and informative, thanks. Do you have any tips on how to get them to do a proper test of the new features? I don't like giving them a build from the `develop` branch, but was considering creating a second release branch for them to test from, something like `release/v1.1`. Git Flow in SourceTree doesn't allow two simultaneous release branches, but I can't see a specific problem with it…? – jowie Aug 11 '14 at 16:03
  • As for the ambiguous bit you just pointed out, I guess I meant that I would create a branch called something like `qa` from `release/v1.0.1`, and then merge my feature branch into `qa`. This doesn't matter so much now, because the features were finished today and merged back to `develop`. I've also now merged all the bug fixes from `release/v1.0.1` to `develop` as you suggested. Now I just need to know how best for QA to test the new features for the following release. Should I create a `release/v1.1`? There *may* be further features to add, though. – jowie Aug 11 '14 at 16:11
  • 2
    Okay thanks. I guess Git Flow is only designed for a linear testing workflow, which is sensible. Unfortunately it's not easy to fit that into my real world scenario, but I might go along the lines you suggested and create an intermediate release branch. Having two release branches messes with the build numbers anyway! – jowie Aug 11 '14 at 17:54
  • 1
    We always (and I think should always) test on the feature branch before merging back to develop, so that the cost of fixing a new bug that arises can be weighed vs. the value of the feature (so it doesn't hold up the release.) Though we merge from develop to feature right before QA, during high-traffic times, there are often other features coming in, and we've caught problems that slip onto develop in non-trivial merges after testing. I can't think of a robust solution other than a second full round of QA for each feature on develop, and I'm wondering how others deal with this. – Joshua Goldberg Apr 10 '15 at 16:55
  • @JoshuaGoldberg, this comment would make a great SO question on it's own as this thread is nearly a year old now. – Ramy Apr 20 '15 at 14:14
  • I did add a question on _programmers_, but didn't see a lot of attention there. Is it appropriate to add a duplicate on SO? http://programmers.stackexchange.com/questions/279299/how-do-you-get-complete-testing-qa-in-a-git-hg-flow-development-process – Joshua Goldberg Apr 20 '15 at 16:13
  • @JoshuaGoldberg [cross-posting is frowned upon...](http://meta.stackexchange.com/tags/cross-posting/info) – gnat Apr 20 '15 at 16:37
  • @jubobs, of the two feature branches in the example image that you shared initially, if you look at the feature on the left there is a down arrow pointing at each subsequent commit The feature branch on the right has side-to-side arrows because it's merged into develop, then deleted 1-git checkout develop, 2-git merge --no-ff myfeature, 3-git branch -d myfeature 4-git push origin develop The branch is then recreated off of develop after the 1.0 release is cut. There is no merging of develop into the feature release branch directly, at least in the example. – EMuentes Jan 11 '16 at 18:28