使用功能、故事和任务分支？答案

【问题标题】：Using feature, story and task branches?使用功能、故事和任务分支？
【发布时间】：2017-06-08 01:01:10
【问题描述】：

我们正在使用 Visual Studio Team Services (VSTS)，其中包含史诗、功能、故事和任务。我们还将关注git dmz flow，其中在功能分支中进行开发。我们想使用 VSTS 结构，但又不破坏 git dmz flow 的原则和好处。

我正在考虑有一个 feature 分支 将分支到 story 分支 和 story 分支将分支到 task 分支（实际开发工作发生的地方）。这不会给开发团队增加太多开销吗？自动化可以在这方面提供帮助吗？

我正在考虑使用特性分支之类的故事分支（在 git dmz 流上下文中），其中，当故事完成后，您可以将 PR 转到 dmz 分支（但它会破坏 VSTS/敏捷结构中的结构?)

我认为任务可以在一天内完成，因此任务分支应该是短暂的。我还假设功能需要几天才能完成。

【问题讨论】：

标签： git architecture branch azure-devops branching-strategy

【解决方案1】：

您似乎已将工作项和分支捆绑在一起。

在 Git DMZ Flow 中，它讨论了如何使用不同的分支来有效地构建/发布您的项目。而且这篇文章与WIT（工作项类型）无关。

另一方面，分支和工作项通常不是一对一的对应关系，而是一对多的关系。这意味着您准备在功能分支上开发的内容可以通过工作项中的详细操作列出。

例如，有一个功能分支需要为公司导出报表，这里称分支名称为feature/reporting。现在，您可以在工作项中列出此功能的详细工作：

  |___ daily report                (User story)
  |         |___ template design   (task)
  |         |___ function develop  (task)
  |         |___ QA test           (task)
  |___ monthly report              (User story)
  |         |___ …                 (task)
  |___ yearly report               (User story)
            |___ …                 (task)

【讨论】：

谢谢！是的，看起来这就是为什么它让我有点困惑。我认为我们将从功能分支分支到任务分支，并且不会使用故事分支。您对此有何看法？
没有必要创建这么多分支。如上例中列出的用户故事和任务，都只是支持顺利开发feature/reporting的功能。所以你只需要从mastercheckout 功能分支就够了。