TFS——级联分支的可持续性

Question

分支指南通常描述一个不朽的“主”分支，具有从主分支分支的功能，并合并回主分支，以及从主分支分支的版本，以及服务包、RTM 等所需的版本的进一步分支。关于主分支的指南是通常被简化为“主城区没有垃圾”。

我正在与一个定期（每月）连续发布的团队合作。对他们来说，似乎没有必要将工作返回到主分支。他们使用 TFS 2010 - 从图表上看，他们的分支结构如下所示：

在分支上进行每日构建；最终该分支投入生产。分支的任何修补程序都会直接应用于该分支，并且可以选择向前合并到任何未来运行中的分支。

该组织的分支策略被戏谑地描述为“级联分支反模式”。但考虑到这些分支发布到生产环境，然后（通常）有相当短的生存时间，真的是这样吗？

从长远来看，TFS 中级联分支的这种做法是否可持续。如果不是，限制是什么？何时（在多少个分支之后）可能达到限制？

是否有任何理由最终不“销毁”Main、R1、R2（等），或者是否存在阻止销毁和回收托管源代码存储库的 SQL Server 上的空间的“陷阱”？

Answer 1

级联分支可以工作。我也想不出任何技术原因为什么销毁非常旧的（最好是存档的）分支会影响较新的级联分支。以下是需要考虑的一些问题：

1. 开发人员必须在每次发布后将新分支映射到他们的工作区。
2. 如果开发人员无法在发布前签入任何工作（而不是在发布后签入相同的工作 Dev 或 Main 分支），则必须手动将任何工作移至新分支。
3. 如果您有一名或多名开发人员在Rn 的子分支，并决定将其工作移至 Rn+1，则需要进行无基础合并以避免签入原始父 Rn 分支。
4. 释放后请确保安全锁定每个分支。所有这些分支都会增加开发人员意外签入已发布分支更改的风险。
5. 您需要在每次级联后调整构建定义和任何其他特定于路径的工件。如果所有开发都在 Dev（或 Main）之外进行，那么主工作区和相关的构建/项目工件将随着时间的推移保持不变。
6. 当您不知道哪些功能将在 Rn 中发布时，如何单独处理并行功能？ （如果您有一个主分支，则可以从主分支拥有多个子功能开发分支，然后仅当功能分支稳定并准备好合并以在下一个版本中发布时才合并功能分支。）

我相信 Jeff Levinson 做了一个演示，描述了分支演化从单个分支开始，然后是级联分支，然后是 Main+Release 和几个变体（同时描述每个分支的优缺点）。查看分支和合并实践 - Jeff Levinson（Teched 2010 视频）（或相关分支与合并 PPT）。

享受！ -Zephan