针对Hotfix和RC存在的Git流澄清？

Question

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

当存在挂起的RC时，修补程序不应该存在（或者可以，但很快）。

看这个图像：

如果有待处理的RC正在暂存，并且尚未完全测试，并且突然需要紧急修补程序，该怎么办？

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

但即将到来的RC呢？

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

那么我们应该取消RC吗？但那时dev与RC分支时的不一样

题

假设有一个待完成的非完全测试的RC和一个紧急修补程序，应该用RC做什么？

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

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

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

Answer 1

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

如果你有这种非线性开发，无序开发工作（如修补程序），你会使用'gitworkflow'（一个词，也就是introduced here）：Git repo itself使用的工作流程。

使用Gitworkflow，您的RC would be in master和maint branch中的修补程序（与Git Flow相反）可以根据需要合并到master。 （注意：并非所有的修补程序都需要向后移植/合并到master或dev：有时，您在当前的生产版本中进行热修复，这在下一个开发周期中不再相关）。

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

然后dev (called next)和pu (for experimentation)被简单地重置/重新创建，由于Git 2.18 brings git rebase --rebase-merges，它们各自的选择特征分支已经合并在其中。

Answer 2

你说：

Git流说我们不应该将修补程序合并到RC。

但阅读the Gitflow page我在“完成修补程序分支”中完全相反：

此处规则的一个例外是，当发布分支当前存在时，需要将修补程序更改合并到该发布分支中，而不是开发。在发布分支完成时，将错误修复反向合并到发布分支中最终将导致错误修复合并到开发中。 （如果立即开发工作需要这个错误修复，并且不能等待发布分支完成，您可以安全地将错误修复合并到开发中。）

所以没有问题:-)