We've been using git flow for our iOS projects happily for a while now. However, something dawned on me today which means we're actually not following the git flow specification.
When we start doing the final testing of a release, we release a BETA version to several hundred people within our organization. Now, this BETA is basically a Release Candidate since no additional bugs may be found in which case it's ready for App Store release. Since there's 7+ days of review time we always upload this BETA to iTunes Connect and set it to wait for review.
We release this BETA from a tag on the master branch after merging in its release branch. However, git flow dictates that the master branch must reflect what is currently in production. Now, there will always be a wait time until it's actually in production (so we can't not break the git flow model), but if serious bugs are found in this BETA, we remove it from the review queue meaning it's not going to be released, and now the latest commit on master is not reflective of what's going to be in production.
How do you get around this in your workflow?
We release this BETA from a tag on the master branch after merging in its release branch. However, git flow dictates that the master branch must reflect what is currently in production.
So, why would you do that if the BETA is not currently in production? :)
I mean, the
release branch is meant precisely to track the lifecycle of release candidates while they are being evaluated, regardless if that means internal testing, beta users testing or, why not, App Store review process.
So, I’d suggest you keep the
release branch open during the entire lifecycle of your BETA and build from there the version submitted to the App Store:
releasebranch (which merges all changes both to
develop) and set it live on the App Store.