Gitflow Release Tagging Model Creates A Dilemma

Question

I'm looking to implement the gitflow branching model at work, as first laid out in http://nvie.com/posts/a-successful-git-branching-model/ or at the Atalssian site at https://www.atlassian.com/git/workflows#!workflow-gitflow . One thing bothers me though and I'm looking for clarification. Once we have a release branch and think its ready we deliver it to QA. They do testing and there is some back and forth of bug reporting and fixing, finally we reach a point where we deliver to QA from the release branch and they accept it, so its ready for release. At this point I would think you would

a) ship the exact same build that was accepted to production

b) tag the git repo code from which this build was done, which would be pointing at the end of your release branch

c) do other bookkeeping to merge the release branch back to dev and master

Instead, gitflow suggest we do c) above and tag the master branch. This would mean either that

a) the build we shipped to production in a) above does NOT correspond exactly to the code the tag points at

or

b) or we do a new build from the newly tagged master branch and ship that, but that would mean what we ship does not correspond exactly to what QA tested and accepted, its a new build

Both of these seem bad. Has anyone encountered similar thoughts? And what solution did you implement.

Thanks.

Answer 1

The only way commits get into master is by being included in a release branch or a hotfix. And hotfixes are merged into release branches¹. So, when you perform the merge of your release branch into master, it should be a trivial merge and result in the same tree as in your release branch.

To verify this, you can do a git diff release master (or equivalently, git diff master^2 master, i.e. diff the merged commit on the master branch with its 2nd parent, which is the tip of your release branch).

[1] This is a special case that's only mentioned in-line in the text, not in the headings, and may not be implemented in the git flow automation scripts.