Git 对 Hotfix 和 RC 的存在进行流程说明？
Git flow clarification for the existence of both Hotfix and RC?
同时存在 RC 和 Hotfix 的常见方法是：
Hotfix should not exists
(or can, but very shortly) the same time while there is a pending RC.
查看这张图片：
如果有一个待定的 RC 正在暂存中，尚未完全测试，突然需要紧急修补程序怎么办？
当然我们会创建一个修补程序分支，修复它，然后合并回 dev 和 master。
但是待定的 RC 呢？
- 它不包含更改。
- Git 流说我们不应该将修补程序合并到 RC。
- 我们不能相信修复是在master上，因为严格来说，RC应该作为一个整体上传和测试。
那么我们应该取消 RC 吗？但是 dev 将与 RC 分支时不同
问题
假设有一个待定的未完全测试的 RC 和一个紧急的修补程序，在 RC 方面应该做什么？
即使我们将 RC（没有修补程序）上传到 master（包含修补程序）- 只有下一个 RC 将包含修补程序（因为开发与修补程序合并）- 但它说一个从未用修补程序测试过的 RC - 将被上传!!!
我没有找到关于这些场景的信息。
我们应该如何处理 RC 和修补程序？
这就是你不使用 gitflow 的原因。
如果你有那种非线性开发，有乱序的开发工作（比如修补程序），你会使用'" (one word, also ): the workflow used by the Git repo itself.
使用 Git 工作流程，您的 RC would be in master, and your hotfix in a maint branch（与 Git 流程相反）可以在需要时合并到 master。
（注意：并非 所有 修补程序都需要 backported/merged 到 master 或 dev：有时，您在当前生产版本中进行修补程序这在下一个开发周期中不再相关）。
与 Git 流程的另一个区别：“public”和“next”（又名“devel”）分支永远不会合并到 master.它们是 "transient" 或 "ephemeral"，总是 deleted/recreated。
只有功能分支会合并到生命周期分支（public、next、master）。这意味着您可以随时选择在开发生命周期的一个阶段和下一阶段之间删除功能。
master 可以随时从“maint”（修补程序）接收合并。
然后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.
你说：
Git flow says we should not merge the hotfix to RC.
但是阅读 the Gitflow page 我在 "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.)
所以没有问题:-)
同时存在 RC 和 Hotfix 的常见方法是：
Hotfix should not exists (or can, but very shortly) the same time while there is a pending RC.
查看这张图片：
如果有一个待定的 RC 正在暂存中，尚未完全测试，突然需要紧急修补程序怎么办？
当然我们会创建一个修补程序分支，修复它，然后合并回 dev 和 master。
但是待定的 RC 呢？
- 它不包含更改。
- Git 流说我们不应该将修补程序合并到 RC。
- 我们不能相信修复是在master上，因为严格来说，RC应该作为一个整体上传和测试。
那么我们应该取消 RC 吗？但是 dev 将与 RC 分支时不同
问题
假设有一个待定的未完全测试的 RC 和一个紧急的修补程序，在 RC 方面应该做什么？
即使我们将 RC（没有修补程序）上传到 master（包含修补程序）- 只有下一个 RC 将包含修补程序（因为开发与修补程序合并）- 但它说一个从未用修补程序测试过的 RC - 将被上传!!!
我没有找到关于这些场景的信息。
我们应该如何处理 RC 和修补程序？
这就是你不使用 gitflow 的原因。
如果你有那种非线性开发，有乱序的开发工作（比如修补程序），你会使用'
使用 Git 工作流程，您的 RC would be in master, and your hotfix in a maint branch（与 Git 流程相反）可以在需要时合并到 master。
（注意：并非 所有 修补程序都需要 backported/merged 到 master 或 dev：有时，您在当前生产版本中进行修补程序这在下一个开发周期中不再相关）。
与 Git 流程的另一个区别：“public”和“next”（又名“devel”）分支永远不会合并到 master.它们是 "transient" 或 "ephemeral"，总是 deleted/recreated。
只有功能分支会合并到生命周期分支（public、next、master）。这意味着您可以随时选择在开发生命周期的一个阶段和下一阶段之间删除功能。
master 可以随时从“maint”（修补程序）接收合并。
然后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.
你说：
Git flow says we should not merge the hotfix to RC.
但是阅读 the Gitflow page 我在 "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.)
所以没有问题:-)