我应该在 Git Flow 中拥有长期功能分支吗？

Question

我正在与一个团队一起使用 Git Flow。我们都从功能开发中分支出来，并在代码审查后合并回来。它对我们来说效果很好，但是我们现在有一个功能需要开发人员一个多月才能完成。这段时间我们将发布一些版本。

有几个问题可以推动这一点：

• 我们应该如何处理这个问题？
• 我们应该这样处理吗？
• 或者我们应该将该功能分解为更小的合并请求？
• 如果我们将其拆分，并且它是一个公共项目，我们如何确保此功能的一部分不会影响正在进行的版本？
• 将开发合并到这个长期功能分支真的那么糟糕吗？我的同事担心这是反模式。
• 如果我们不将开发一致地合并回这个长期功能中，那么当该功能最终完成时，难道不会产生不良后果吗？

Answer 1

这在我的工作场所也很常见。我们按每周发布计划进行工作，因此每周三都会有新功能投入生产。正因为如此，几乎总是有一些功能是半生不熟的，而且还没有准备好投入生产。

因此，对于长期分支，以下是对我们最有效的方法：

• 正常分支该功能 ( feature-1)
• 切断分支后feature-1，工作就可以正常开始了。
• 如果功能足够大，则分解为更小的子任务。（例如，创建服务；将服务实现到控制器中；等等）
• feature-1然后针对功能的每个增量更新（sub-task-1、等）进行分支，并在子任务完成时sub-task-2合并回来。feature-1（这允许feature-1仅包含全功能代码）
• 当开发feature-1和子任务进展时，重要的是，当 PR 被合并到 时develop，您需要对feature-1分支进行变基。在准备功能 PR 时，不这样做通常会导致大型变基。

正如您所注意到的，这与您的正常工作流程没有太大的区别，这更多的是一个纪律问题，以确保经常进行变基，并且半生不熟的代码不会进入develop.

希望这可以帮助。

Answer 2

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

请注意顶部附近的图像。它指出了未来版本的功能（因此，是一个长期功能）。

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