我应该在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的blog post。

注意顶部附近的图像。它注意到未来发布的功能（因此，这是一个长期功能）。

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

Answer 3

在之前的公司，我们至少有1/3的分支机构“长期运行”至少2周或更长时间（一个月开发的分支机构非常普遍）。我们也使用gitflow模式。基本上我们会在分支机构上工作，并定期在我们的分支上开发和修改我们的分支。这非常类似于将开发合并到一个我知道被认为是反模式的特征分支。

真正的关键是维护分支机构，而不是让它落后太远。过时的分支是最痛苦的尝试和更新有时。考虑您是否有时间跟上分支机构以及其他优先事项，需要考虑在内。

测试/环境设置也很重要。拥有一个长期运行的分支意味着它很可能是一个重要的特征/变化，因此它也可能会被测试。如果您的QA'ers（无论是团队还是您自己和其他开发人员）可以在分支环境中接近准备时对分支进行测试，那么这将有助于实现这一目标。