git - Git 流程澄清 Hotfix 和 RC 的存在？

问题描述

存在 RC 和 Hotfix 的常见方法是：

有待处理的 RC 时，修补程序不应该存在 _{（或可以，但很快）。}

看着这张图片：

如果有一个挂起的 RC 正在暂存，但尚未完全测试，突然需要紧急修补程序怎么办？

当然，我们会创建一个修补程序分支，修复它，然后合并回 dev 和 master。

但是待定的 RC 呢？

它不包含更改。
Git 流程说我们不应该将修补程序合并到 RC。
我们不能相信修复是在 master 上，因为严格来说，RC 应该作为一个整体上传和测试。

那么我们应该取消 RC 吗？但随后 dev 将与 RC 分支时不同

问题

假设有一个未完成的未完全测试的 RC 和一个紧急修复程序，那么在 RC 方面应该做什么？

即使我们将 RC（没有修补程序）上传到 master（包含修补程序）——只有下一个 RC 将包含修补程序（因为 dev 与修补程序合并）——但它表示从未测试过的 RC修补程序 - 将被上传！

我没有找到有关这些场景的此类信息。

我们应该如何处理 RC 和修补程序？

标签： gitgit-flow

这就是你不使用 gitflow 的原因。

如果您有这种非线性开发，以及无序开发工作（如修补程序），您将使用“ gitworkflow ”（一个词，这里也有介绍）：Git 存储库本身使用的工作流。

使用 Gitworkflow，您的RC 将位于中master，并且您的修补程序位于maint分支中（与 Git Flow 相反），然后可以master在需要时合并到该分支中。
（注意：并非所有修补程序都需要向后移植/合并到master或dev：有时，您在当前的生产版本中修补了在下一个开发周期中不再相关的东西）。

与 Git Flow 的另一个区别：“ public”和“ next”（又名 ' devel'）分支永远不会合并到master. 它们是“暂时的”或“短暂的”，总是被删除/重新创建。
只有功能分支会合并到生命周期分支 ( public, next, master)。这意味着您可以随时选择在开发生命周期的一个阶段和下一阶段之间放弃一项功能。
并且可以随时从“”（修补程序）master接收合并。maint

然后dev（称为next）和pu（用于实验）简单地重置/重新创建，它们各自选择的功能分支已经合并在其中，因为Git 2.18 带来了git rebase --rebase-merges.

git - Git 流程澄清 Hotfix 和 RC 的存在？

问题描述

解决方案

推荐阅读