3

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

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

  • 我们应该如何处理？
  • 我们应该这样处理吗？
  • 还是我们应该将功能拆分成更小的合并请求？
  • 如果我们将其拆分，并且它是一个公共项目，我们如何确保此功能的某些部分不会影响正在进行的发布？
  • 合并开发到这个长期的特性分支真的那么糟糕吗？我的同行担心它是反模式的。
  • 如果我们不将开发一致地合并回这个长期功能，当功能最终完成时会不会产生不好的后果？
4

3 回答 3

4

这在我的工作场所也很常见。我们按每周发布时间表工作，因此每个星期三都有新功能投入生产。正因为如此，几乎总是有半生不熟的功能，而不是生产就绪。

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

  • 正常分支功能 ( feature-1)
  • 随着feature-1分支的切割，工作正常开始。
  • 如果特征足够大，分解成更小的子任务。（例如，创建服务；将服务实现到控制器中；等等）
  • feature-1然后为功能的每个增量更新分支（ sub-task-1，等），当子任务完成时sub-task-2合并回来。feature-1（这允许feature-1只包含全功能代码）
  • 在开发feature-1和子任务进展的同时，重要的是当 PR 被合并到develop中时，你重新设置feature-1分支。在准备功能 PR 时，不这样做通常会导致大型 rebase。

正如您所注意到的，您的正常工作流程并没有太多的转移，更多的是一个纪律问题，以确保经常进行变基并且半生不熟的代码不会使其成为develop.

希望这可以帮助。

于 2015-11-06T19:24:39.093 回答
2

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

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

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

于 2015-11-06T16:06:42.010 回答
1

在以前的公司，我们至少有 1/3 的分支机构“长期运行”至少 2 周或更长时间（开发一个月的分支机构很常见）。我们也使用了 gitflow 模式。基本上，我们会在分支上工作，并定期在其上拉取开发和变基我们的分支。这与将开发合并到一个我知道被认为是反模式的特性分支非常相似。

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

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

于 2015-11-06T16:31:59.897 回答