version-control - TFS——级联分支机构的可持续性

Question

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

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

每天在一个分支上构建；最终该分支机构投入生产。分支的任何修补程序都直接应用于该分支，并可选择合并到任何 future 的飞行分支。

这个小组的分支策略被贬低地描述为“级联分支反模式”。但考虑到这些分支发布到生产环境，然后(通常)只有很短的生存时间，真的吗？

这种在 TFS 中级联分支的做法是否可以长期持续。如果没有，限制是什么，什么时候(在多少个分支之后)可以达到？

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

Answer 1

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

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

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

尽情享受吧! -Zephan