Team Foundation Server 开发结构
我是一个小型开发团队的成员，该团队正在从 Visual Source Safe 迁移到 TFS2010。
我一直在阅读有关 TFS 结构的内容，并遇到了一个非常好的问题。
上面链接中提到的一件事我不确定是开发结构：
- Development/
- Trunk/
- Source/
- etc/
- Branches/
- Source/
- etc/
我真的不明白 Trunk 和 Branches 作为单独的子项的需要容器到开发。我如何阅读这个结构是Trunk将从Integration（或Main，如果您使用MS术语）和Branches<分支出来/code> 然后将从 Trunk 分支（即 Trunk 是多个 Branches 的父级）。
如果是这样的话，我不明白层次结构中额外层的优势。对我来说，合乎逻辑的是（记得我已经学习这些东西大约一天了），如果您想要多个开发分支，则将每个开发分支作为 Development 容器的子级
- Development/
- DevBranchOne/
- Source/
- etc/
- DevBranchTwo/
- Source/
- etc/
：上述结构（其中 DevBranchOne 和 DevBranchTwo 被替换为有意义的名称），开发分支是同级分支，并且所有分支都来自 Integration （或 主要）。鉴于上述情况，我的问题是：
- 我对
开发中Trunk的预期用途的理解是否正确？ - 如果我的第一个问题的答案是肯定的，那么在
开发中实现这样的层次结构有什么好处？ Trunk的使用只是从 SVN 继承过来的吗（我对此没有任何经验）？
I'm a part of a small development team who are in the process of moving from Visual Source Safe to TFS2010.
I've been reading about TFS structure and came across a very good question.
One thing mentioned in the above link which I'm not sure about is the Development structure:
- Development/
- Trunk/
- Source/
- etc/
- Branches/
- Source/
- etc/
I don't really understand the need for the Trunk and Branches as separate children containers to Development. How I'm reading this structure is that Trunk would branch from Integration (or Main if you use MS terminology) and Branches would then branch from Trunk (i.e. Trunk is the parent to multiple Branches).
If this is the case, I don't understand the advantage of the extra layer in the hierarchy. What seems logical to me (remembering that I've been learning this stuff for about a day) is that if you want multiple development branches, to have each development branch as a child of the Development container:
- Development/
- DevBranchOne/
- Source/
- etc/
- DevBranchTwo/
- Source/
- etc/
In the above structure (where DevBranchOne and DevBranchTwo are replaced with meaningful names), development branches are siblings and all branching from Integration (or Main). Given the above, my questions are:
- Is my understanding of the intended use of the
TrunkinDevelopmentcorrect? - If the answer to my first question is yes, what is the advantage of implementing such a hierarchy in
Development? - Is the use of
Trunksimply something that has been carried over from SVN (with which I have no experience)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我同意，在您链接到的帖子中，他似乎有 2 个“主干”，即开发\主干和集成，这只是他上下文中主干的另一个名称。
根据您的分支策略，您通常只想有一个“主干”（或集成分支）。
但是，在某些情况下，您可能需要多个集成分支，例如，如果您正在执行按功能分支之类的操作，但您还有功能组的概念，其中需要将各个功能分支集成到功能组中，在集成到子系统的集成分支之前，该分支随后将集成到产品的主集成分支（又名主干）中。
然而，大多数分支策略只需要一个集成分支。
I agree, in the post you linked to it appears he has 2 "trunks", the Development\Trunk and Integration which is just another name for trunk in his context it appears.
Depending on your branching strategy you usually only want to have one "trunk" (or integration branch).
However, there are some scenarios where you might want multiple integration branches, such as if you are doing something like branch by feature, but you also have a concept of feature groups where the various feature branches need to be integrated together into the feature group, before being integrated into the subsystem's integration branch, which then will later integrate into the products main integration branch (aka trunk).
However, most branching strategies only require a single integration branch.
我不一定建议使用这个其他问题作为模型。听起来他们正在将多个功能分支汇总到一个集成分支（“主干”）中，然后进一步集成到另一个集成分支（“集成”）中。这似乎是一个旨在适应他们现有工作流程的分支系统 - 虽然这个系统肯定没有任何问题，但它不适合我的工作流程，您必须更改您的工作流程才能采用。
换句话说，您可能已经知道您是否想要一个像该问题中所描述的那样的分支系统。您对预期内容的描述可能是一个很好的起点：多个开发分支和一个主干（或主干，或任何您想称之为的东西）分支。
如果您还没有，请务必查看 Visual Studio ALM Rangers 中的 TFS 分支最佳实践 。
I would not necessarily recommend using this other question as a model. It sounds like they're rolling up multiple feature branches into an integration branch ("Trunk") and then further integrating into yet another integration branch ("Integration"). This seems like a branching system meant to fit their existing workflow - while there's certainly nothing wrong with this system, it doesn't fit into my workflow, and you'd have to change yours to adopt.
In other words, you'd probably already know if you wanted a branch system like what's described in that question. Your description of what you're anticipating is probably a good starting point: multiple development branches and a single trunk (or main, or whatever you want to call it) branch.
If you haven't yet, be sure to check out the TFS branching best practices from the Visual Studio ALM Rangers.