问题
A common approach to the existence of both RC and Hotfix is:
Hotfix should not exists (or can, but very shortly) the same time while there is a pending RC.
Looking at this image :
What if there is a pending RC which is on staging, and wasn't fully tested yet, and suddenly there is a need for an urgent hotfix?
Sure we would then create a hotfix branch, fix it, and merge back to dev and master.
But what about the pending RC ?
- It doesn't contain the change.
- Git flow says we should not merge the hotfix to RC.
- We can't trust the fix is on master, because strictly speaking, RC should be uploaded and tested as a whole.
So should we then cancel the RC ? but then dev would not be the same as it was when RC was branched
Question
Assuming there is a pending non-fully-tested-RC, and an urgent hotfix, what should be done in terms of RC?
Even if we upload the RC (without the hotfix) to master (which contains the hotfix) - only the next RC will contain the hotfix (becuase of the dev merge with hotfix) - but it says that an RC which was never tested with the hotfix - is going to be uploaded !!!
I didn't find such information about those kinds of scenarios.
How should we deal with RC's and hotfixes?
回答1:
That is why you don't use gitflow.
If you have that kind of non-linear development, with out-of-sequence development effort (like an hotfix), you would use 'gitworkflow" (one word, also introduced here): the workflow used by the Git repo itself.
With Gitworkflow, your RC would be in master, and your hotfix in a maint branch which (contrary to Git Flow) can then be merged to master if needed.
(note: not all hotfixes need to be backported/merged to master or dev: sometime, you are hot-fixing in the current production release something which is no longer relevant in the next development cycle).
The other difference with Git Flow: "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.
Only feature branches are merged to the lifecycle branches (public, next, master). That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.
And master can receive a merge from 'maint' (hotfixes) at anytime.
Then dev (called next) and pu (for experimentation) are simply reset/recreated, with their respective selecgted feature branches already merged in them, since Git 2.18 brings git rebase --rebase-merges.
回答2:
You say:
Git flow says we should not merge the hotfix to RC.
But reading the Gitflow page I read the exact opposite in "Finishing a hotfix branch":
The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)
So there is no problem :-)
来源：https://stackoverflow.com/questions/55075895/git-flow-clarification-for-the-existence-of-both-hotfix-and-rc