Git流是否同时存在修补程序和RC？

存在RC和修补程序的常见方法是：

修补程序不应存在 （或者可以，但很快）在有未决RC的同时

看看这张图片：

如果有一个挂起的RC正在登台，并且还没有完全测试，突然需要一个紧急修补程序，该怎么办

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

但未决的RC呢

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

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

问题

假设有一个未经全面测试的待处理RC和一个紧急修补程序，在RC方面应该做些什么

即使我们将RC（不带修补程序）上传到master（包含修补程序）-只有下一个RC将包含修补程序（因为开发人员与修补程序合并）-但它说从未使用修补程序测试过的RC将被上传

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

---

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

这就是为什么不使用gitflow的原因

如果您有这种非线性开发，并且开发工作没有顺序（如修补程序），那么您将使用''（一个词，也可以使用）：工作流所使用的工作流

有了Gitworkflow，您和您的修补程序（与Git流程相反）就可以在需要时合并到

master

。
（注意：并非所有热修复程序都需要后端口/合并到

master

或

dev

：有时，您在当前生产版本中热修复了一些在下一个开发周期中不再相关的内容）

Git流的另一个区别是：“

public

”和“

next

”（又名“

devel

”）分支从不合并到

master

。它们是“暂时的”或“短暂的”，总是被删除/重新创建。
只有功能分支合并到生命周期分支（

public

，

next

，

master

）。这意味着您可以随时选择在开发生命周期的一个阶段和下一个阶段之间删除功能。
和

master

可以随时从“

maint

”（修补程序）接收合并

然后，和被简单地重置/重新创建，它们各自选择的特征分支已经合并到它们中，因为。

你说：

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

但在阅读中，我读到了与“完成修补程序分支”完全相反的内容：

这里规则的一个例外是，当发布分支当前存在时，需要将热修复更改合并到该发布分支中，而不是“开发”。（如果develope中的工作立即需要此错误修复，并且不能等待发布分支完成，那么您也可以安全地将该错误修复合并到develope中。）

---

所以没有问题：-）

很有趣……有什么官方的地方可以找到吗？或者只是一个人的建议……因为如果我将修补程序合并到RC，那么开发人员呢？我会将RC上传到master，然后将修补程序下载到开发人员？我发布的链接指向帖子“一个成功的Git分支模型”文森特·德里森写道。他是那个模型的“发明者”。所以我认为这个帖子是官方的。你的第二个问题：在我引用的段落中有解释：HF被合并到RC，RC又被合并到

develope

。在atlassian，他们讨论了4个流。是其中之一吗？我想看看它们之间的区别，这样我就很容易学习了。@RoyiNamir你能给我Atlassian页面的URL吗？@RoyiNamir不，它不在列表中。它更接近gitflow（），但我在上面的回答中解释了它们的区别。我甚至没有找到关于它的youtube视频。非常奇怪的是，它并没有出名。@RoyinamirGitflow很早，很容易理解，但效率较低。gitworkflow具有优越性，并在中显示。