在Git Flow中，我是否应该拥有长期的特性分支？

Question

我正在与一个团队一起使用Git Flow。我们都从develop分支上创建功能分支，并在代码审查后合并回来。这对我们来说效果很好，但现在有一个开发人员将需要超过一个月的时间才能完成的功能。在此期间，我们将有几个版本发布。

以下是一些引导性问题:

• 我们应该如何处理这种情况？
• 我们是否应该以这种方式处理？
• 或者我们应该把这个功能分解成更小的合并请求？
• 如果我们把它拆分开来，并且它是一个公共项目，我们该如何确保这个功能的各个部分不会影响正在进行的版本发布？
• 把develop分支合并到这个长期功能分支中真的很糟糕吗？我的同事们担心这是反模式。
• 如果我们不会定期地将develop分支合并到这个长期功能分支中，当功能最终完成时会不会产生不良后果？

- mikegertrudes

---

这是一个有趣的问题，尽管它是主观的。通常的建议是不要使用长期特性分支，将所有特性分解成较小的组件，这在理论上很好，但不幸的是在实践中并不起作用。 - raina77ow

您也可以每周将主分支合并到您的功能分支中，以确保您的功能分支始终与最新的主分支兼容。 - edi9999

Answer 1

这在我的工作场所也很常见。我们按周发布计划工作，因此每个星期三都会有新功能上线。因此，几乎总是有一些功能还未完全成熟，无法投入生产。

关于长期分支，以下是我们最好的做法：

1.像平常一样为功能创建分支（feature-1）； 2.随着 feature-1 分支的创建，工作正常开始； 3.如果该功能足够大，则将其拆分为较小的子任务。（例如，创建服务；将服务实现到控制器等）； 4.然后为每个增量更新的功能分支 (sub-task-1, sub-task-2 等)，并在完成子任务时合并回 feature-1。这样可以使 feature-1 只包含完整的功能代码； 5.在开发 feature-1 和子任务时，重要的是要定期进行变基操作，以便将 PR 合并到 develop 分支。否则，当准备功能 PR 时通常需要进行大量的变基操作。

正如您注意到的那样，与您的正常工作流程相比，并没有太多的偏离，而更多的是要纪律性地确保经常进行变基操作，并且半成品代码不会进入 develop 分支。

希望这能有所帮助。

- Paul Barry

---

你们的开发中是否会出现半成品功能？或者说，这些功能会一直停留在feature-1分支上直到完全完成吗？换句话说，即使处于休眠状态，半成品功能是否会进入生产环境？ - mikegertrudes

Answer 2

我无法以强硬的立场回答你的问题，但我可以指向一篇关于gitflow的博客文章。

请注意顶部附近的图像。它标注了一个将来的发布功能（因此是长期功能）。

这使我相信，当情况需要时，这是必要的适当行为。

- dlstadther

Answer 3

在我之前的公司，至少有三分之一的分支是“长时间运行”的，持续时间至少为两周或更长时间（一个月内开发的分支很常见）。我们也使用了gitflow模式。基本上，我们会在分支上工作，并定期拉取develop并将我们的分支重新基于其之上进行rebase。这与将develop合并到特性分支中非常相似，我知道这被认为是一种反模式。

真正的关键是维护分支，不让它落后太远。过期的分支有时最难更新。需要考虑是否有时间跟上分支以及其他优先事项。

测试/环境设置也很重要。拥有长时间运行的分支意味着它很可能是一个重要的功能/更改，因此它可能也会像这样进行测试。如果您的QA人员（无论是团队还是您自己和其他开发人员）可以在隔离环境中在分支接近就绪时对其进行测试，那么这将非常有帮助。

- broox9