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

Question

分支指南通常描述一个不朽的“主”分支，其功能从 Main 分支，并合并回 Main，以及从 Main 分支的版本，以及 Service Pack、RTM 等所需的版本的进一步分支。该指南关于 Main 通常被简化为“Main 中没有垃圾”。

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

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

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

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

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

Answer 1

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

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

我相信 Jeff Levinson 做了一个演示，描述了从单个分支开始的分支演变，然后是级联分支，然后是 Main+Release 和几个变体（同时描述了每个分支的优缺点）。查看Branching and Merging Practices - Jeff Levinson (Teched 2010 Video)（或相关Branching & Merging PPT）。

享受吧！ -Zephan