The Git flow model is working well for our company so far, but we're wondering about a solution for handling this hypothetical situation. I searched around a bit, but I think my lack of proper terminology for this case might have stymied my Google-fu.
If all your releases must "be from" a merge commit into the master branch, as detailed here:
A successful Git branching model
Then how do you handle a situation in which you release 0.2.0, then 0.3.0, then 0.2.1? At this point must the release be performed from the 0.2.x development branch (assuming one exists, or is created from the 0.2.0 tag)? Certainly you can't merge back into master, as your patch release is probably a good few commits behind.
Is the best solution then, something like:
git checkout tag-release-0.2.0
git checkout -b some-0.2.1-critical-feature
.. (work) ..
git commit
# At this point, the release-0.2.x-branch is the same as the above release tag
git checkout release-0.2.x-branch
# Merge the feature branch into the patch release branch
git merge some-0.2.1-critical-feature
# NOTE here! Release occurs from the patch branch!
git tag tag-release-0.2.1
# Merge patch fixes into develop
git checkout develop
git merge tag-release-0.2.1
Is there a better solution than this? If the RULE is to merge into master to perform a release, won't any patch releases have to take place prior to the next minor/major?
