分支指南通常描述一个不朽的“Main”分支，其功能从Main分支，并合并回Main，Releases从Main分支，Release的其他分支根据Service Pack，RTM等的需要 . 关于Main的指导是通常简化为“主要没有垃圾” .
我正在与一个定期（经常每月）和连续发布的小组合作 . 对他们来说，似乎没有必要将工作返回到主分支 . 他们使用TFS 2010 - 图解他们的分支结构如下所示：
每日 Build 在分支机构上;最终该分公司投入 生产环境 . 分支的任何修补程序都直接应用于该分支，并可选择合并到任何未来的动态分支 .
该小组的分支战略被称为“级联分支反模式” . 但这是真的吗，鉴于这些分支机构已经投入 生产环境 ，然后（通常）生活的时间相当短暂？
这种TFS分支的实践是否可以长期持续 . 如果没有，有什么限制，何时（在多少个分支之后）可以达到？
有没有理由不最终“破坏”Main，R1，R2（等），还是有一个“陷阱”会阻止托管源代码存储库的SQL服务器上的空间的破坏和回收？
1 回答
级联分支可以工作 . 我也想不出任何技术上的原因，为什么破坏非常古老的（最好存档的）分支会影响较新的级联分支 . 以下是一些需要考虑的问题：
开发人员必须在每次发布后将新分支映射到其工作区 .
开发人员必须手动将任何工作移动到新分支，如果他们在发布之前无法检入它（而不是在发布后检入相同的工作Dev或Main分支 . ）
如果您有一个或多个开发人员在Rn的子分支中工作并且决定将他们的工作移动到Rn 1，那么将需要无基础合并以避免检入原始父Rn分支 .
确认您在发布后安全地锁定每个分支 . 所有这些分支都会增加开发人员意外检查已发布分支的更改的风险 .
您需要在每个级联后调整构建定义和任何其他特定于路径的工件 . 如果所有开发都在Dev（或Main）之外，那么主工作区和相关构建/项目工件将随着时间的推移保持不变 .
当您不知道哪些功能将在Rn中发布时，您如何孤立地处理并行功能？ （如果您有一个主分支，则可以从Main获得多个子功能开发分支，然后仅在功能分支稳定并且准备合并以在下一版本中发布时合并功能分支 . ）
我相信Jeff Levinson做了一个演示文稿，描述了从单个分支开始的分支演化，然后是级联分支，然后是主要版本和几个变体（同时描述每个的优缺点） . 查看Branching and Merging Practices - Jeff Levinson (Teched 2010 Video)（或相关Branching & Merging PPT） .
请享用！ -Zephan