Gitflow Release Tagging Model Creates A Dilemma

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

  • Remove all commits that were merged from a specific branch
  • How To Revert Changes made by Some User in GIT Repository
  • Intellij import issue - java.io.IOException: Cannot run program “git”: error=2, No such file or directory
  • How do I add and commit file in a git repository while in different directory
  • First commit Android Studio Project — What should leave out?
  • Git - How to locally remove a single commit a few commits back?
  • 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.

  • Add a subdirectory of another project as a subtree
  • git push fails in new branch
  • Unable to change where Git is loaded in Mac
  • git: rename file and change the content of the file
  • Best solution for “No Scheme” issue in Xcode 4 after defected merging git branches
  • git checkout previous commit without mouse
  • One Solution collect form web for “Gitflow Release Tagging Model Creates A Dilemma”

    The only way commits get into master is by being included in a release branch or a hotfix. And hotfixes are merged into release branches1. 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.

    Git Baby is a git and github fan, let's start git clone.