Team Foundation Server 开发结构

Question

我是一个小型开发团队的一员，他们正在从 Visual Source Safe 迁移到 TFS2010。

我一直在阅读有关 TFS 结构的信息，遇到了 very good question.

上面链接中提到的我不确定的一件事是开发结构：

- Development/
      - Trunk/
          - Source/
          - etc/
      - Branches/
          - Source/
          - etc/

我真的不明白Trunk 和Branches 需要作为Development 的单独子容器。我如何阅读这个结构是Trunk 将从Integration 分支（或Main，如果您使用MS 术语），然后Branches 将从Trunk 分支（即Trunk 是多个的父级Branches)。

如果是这种情况，我不明白层次结构中额外层的优势。对我来说合乎逻辑的事情（记得我已经学习了大约一天的时间）是，如果您想要多个开发分支，则将每个开发分支都作为 Development 容器的子级：

- Development/
      - DevBranchOne/
          - Source/
          - etc/
      - DevBranchTwo/
          - Source/
          - etc/

在上述结构中（其中DevBranchOne 和DevBranchTwo 被替换为有意义的名称），开发分支是兄弟姐妹，并且都从Integration（或Main）分支。鉴于上述情况，我的问题是：

1. 我对@9​​87654340@ 中Trunk 的预期用途的理解是否正确？
2. 如果我的第一个问题的答案是肯定的，那么在Development 中实现这样的层次结构有什么好处？
3. Trunk 的使用仅仅是从 SVN 继承的东西（我没有经验）吗？

Answer 1

我同意，在您链接到的帖子中，他似乎有 2 个“主干”，即 Development\Trunk 和 Integration，这只是他出现的上下文中主干的另一个名称。

根据您的分支策略，您通常只想拥有一个“主干”（或集成分支）。

但是，在某些情况下，您可能需要多个集成分支，例如，如果您正在执行诸如逐个功能分支之类的操作，但您也有一个功能组的概念，其中各种功能分支需要一起集成到功能组，在集成到子系统的集成分支之前，然后将集成到产品主集成分支（又名主干）中。

但是，大多数分支策略只需要一个集成分支。

Answer 2

我不一定建议使用this other question 作为模型。听起来他们正在将多个功能分支汇总到一个集成分支（“Trunk”）中，然后进一步集成到另一个集成分支（“Integration”）中。这似乎是一个分支系统，旨在适应他们现有的工作流程——虽然这个系统肯定没有问题，但它不适合我的工作流程，你必须改变你的才能采用。

换句话说，您可能已经知道您是否想要一个像该问题中描述的那样的分支系统。您对预期内容的描述可能是一个很好的起点：多个开发分支和一个主干（或主，或任何您想称呼的）分支。

如果您还没有，请务必查看 Visual Studio ALM Rangers 的 TFS branching best practices。