为什么使用GitFlow时需要将release分支合并到develop分支？

Question

我正在学习 Gitflow 工作流程。以下是关于 Gitflow 工作流程的示例图。

我认为A、B、C、D的内容是相同的，对吧？

我认为A合并到C然后C合并到D是可以的，但是为什么需要C合并到B？你知道A和B是一样的！

图像

Answer 1

您关于 A、B、C 和 D 相同的断言是不正确的（至少在此图的上下文中）。

\n\n

在 A 和 C 之间，您会看到有一些提交。这是预料之中的。在“测试”发布分支时，可能会发现一些需要在发布之前纠正的错误。或者可能需要一些维护工作，例如更新源代码中的版本号或类似的工作。

\n\n

无论哪种方式，都会在发布分支上进行更改，因此，一旦完成，这些更改必须带回开发分支，以便它们可以进入下一个版本。

\n\n

现在，说了这么多，有时可能没有对发布分支进行任何其他更改，因此没有必要合并回开发分支。在这些情况下，如果您尝试将发布分支合并回开发分支，git 实际上会告诉您没有什么可做的，因此不会发生合并。

\n\n

关于使用 GitFlow 的原始文章对此进行了记录：

\n\n

\n\n

\n
发布分支支持新生产版本的准备。它们允许在最后一刻对 i\xe2\x80\x99s 进行打点并交叉 t\xe2\x80\x99s。此外，它们还允许进行小错误修复并为发布准备元数据（版本号、构建日期等）。通过在发布分支上完成所有这些工作，开发分支就可以接收下一个大版本的功能。
\n

\n