当开发分支在Git Flow中创建后进展了，如何处理发布分支？

Question

我认为我有一个特殊的情况。我们组织遵循标准的git流程，除了发布分支需要一些时间才能准备好合并回主分支和开发分支。

我们曾经阻止所有功能分支合并到开发分支，直到发布分支合并回主分支和开发分支。然而，随着团队规模的增长，这变得不可接受。因此，我们希望允许开发人员在发布分支合并之前继续将其功能分支合并回开发分支。

现在问题出现在最终合并发布分支的时候。假设在发布r1之前，f1和f2是在开发分支上。从那时起，f3和f4已经合并回开发分支。现在，如果我们合并发布分支r1，开发分支的时间轴如下：

Merge commit of r1
Merge commit of f4
Merge commit of f3
Merge commit of f2
Merge commit of f1

这意味着当下一个版本r2发布时，提交历史记录将包括r1、f4和f3。某些情况下这并不正确。

然而，如果我们在发布分支活动期间阻止合并到develop分支，它看起来会更有组织性，发布提交将出现在它应该出现的地方：

Merge commit of f4
Merge commit of f3
Merge commit of r1
Merge commit of f2
Merge commit of f1

我有哪些选择呢？我不想对develop分支进行交互式的变基，以便重新排序提交记录，因为这样会强制推送到develop分支（有点吓人！）。

- adarshr

---

第一个场景没有任何问题，这就是 git-flow 的工作方式。 - 1615903

你是说“随波逐流”吗？实际上，那可能是最简单、最傻瓜化的方法了。 - adarshr

事实上，发布分支合并回开发分支的时间点不重要——从开发分支分叉的时间点可能是相关的，但这些信息也是可用的。 - 1615903

Answer 1

Git Flow 的主要目的之一是使用 release 分支，以便您不需要在 develop 分支上进行代码冻结。事实上，我可能会说，当您强制执行代码冻结时，Git Flow 对于该情况可能过于复杂。话虽如此，现在您正在进行同时开发，因此您展示的对 develop 持续工作的时间轴是完全正常和预期的。请注意，develop 的历史记录不代表发布到生产的时间轴，而是两条分开的“路径”上的实际同时开发。同样，master（或main）的第一父级历史记录代表了发布到生产的时间轴，可能看起来像：

Merge commit of r3
Merge commit of hotfix2.1
Merge commit of r2
Merge commit of r1

这在 master 或 main 分支中是完全正常且可以预期的。

我认为你不需要改变任何事情。

附注:

1. 通常情况下，release 分支在发布到生产环境之前有时会合并回到 develop 分支。当一个错误修复足够重要，你希望所有新的和正在进行中的工作都能立即访问更改时，通常会发生这种情况。当你这样做时，你将至少有2次将特定的 release 合并回到 develop 的合并，往往还会更多。有些工具甚至可以轻松地自动化反向流程，以便每个完成的 PR 到一个 release 分支自动（如果没有冲突的话）将其合并回到 develop 中。个人而言，我喜欢不要有额外的合并提交用于“将 release 合并到 develop”，所以只有在团队认为必要时才进行额外的手动合并。
2. 在将 release 合并到 master（或 main）之后，我更喜欢将 master 合并到 develop 而不是将 release 合并到 develop。原因很简单，就是为了现在将那个额外的合并提交记录添加到 master 中以便它们不会随着时间的推移而积累，并在你最终有一个 hotfix 时全部带回到 develop 中。这也使得更容易看到 develop，以及任何一个 release 分支都与 master 完全保持同步，因为 develop 的尖端总是可以被 master（或至少是现有的 release 分支）所访问。然后你就知道你不需要担心某个人忘记将热修复合并回去而在 master 上炸掉。

- TTT