TFS - 层叠分支的可持续性

Question

分支引导通常描述一个不朽的“Main”分支，其特征从Main分支出来并合并回Main，并且释放从Main分支出来，进一步分支为Release， ，RTM等。关于Main的指导通常简化为“Main中没有垃圾”。

我正在与定期发布（通常为每月一次）和连续发布的小组合作。对他们来说，似乎没有必要将工作返回到主分支。他们使用TFS 2010 - 图解法的分支结构看起来是这样的：

每日基础上由一个分支;最终该分公司进入生产。任何到分支的修补程序都直接应用到该分支，并可以选择合并到任何未来的在飞行分支中。

这个群体的分支策略被形容为“级联分支反模式”。但是这是否真的如此，因为这些分支发布到生产环境，然后（通常）只有很短的时间才能生存？

这种TFS级联分支机构的做法是否可持续长期。如果不是，有什么限制，什么时候（在多少分支之后）可以达到？

是否有任何理由最终不会“销毁”Main，R1，R2（等），或者是否存在一个“gotcha”，用于防止在托管源代码库的SQL服务器上销毁和回收空间？

Answer 1

级联分支可以工作。我也想不出任何技术上的原因，为什么摧毁非常老的（优选存档的）分支会影响更新的级联分支。以下是需要考虑的一些问题：

1. 开发人员必须在每次发布后将新分支映射到其工作区。
2. 如果开发人员在发布之前无法检查它们，则必须手动将任何工作移动到新分支（而不是在发布后仅检入相同的开发或主分支）。
3. 如果您有一个或多个在Rn的子分支中工作的开发人员决定将他们的工作移动到Rn + 1，然后需要无基本的合并来避免检入原始父Rn分支。
4. 请确保您在发布后确实锁定每个分支。所有这些分支机构都会增加开发商意外检查已发布分支的变更的风险。
5. 您需要在每个级联之后调整构建定义和任何其他路径特定的构件。如果所有的开发工作仅仅依靠开发（或主要），那么主要工作空间和相关的构建/项目工件在一段时间内保持不变。
6. 当您不知道哪些功能将在Rn中出货时，您如何独立处理并行功能？ （如果您有一个主分支，您可以从Main获得多个子特征开发分支，然后仅在稳定时合并特征分支并准备合并才能在下一个版本中发布。）

我相信Jeff莱文森做了一个演讲，描述了从单一分支开始，然后是级联分支，然后是主+释放以及一些变体（同时描述每个分支的优缺点）。检出Branching and Merging Practices - Jeff Levinson (Teched 2010 Video)（或相关的Branching & Merging PPT）。

享受！-Zephan