Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
为 Team Foundation 版本控制（TFVC）存储库创建分支有助于隔离风险。 考虑团队成员在处理由 5 或 10 人以上人员配备的软件项目时通常面临的一些挑战：
该组有一些（或可能有多个）不同的功能团队，每个团队都在处理一组相当独立的功能。 但每个团队还依赖于其他团队构建的功能。 你需要隔离这些团队中完成的工作所引入的更改的风险，但最终需要将所有工作合并到一个产品中。
测试团队需要一个稳定的代码版本进行测试，但同时，开发人员需要继续推进新功能，这些新功能偶尔会破坏产品的稳定性。
该软件有两个以前版本和一个当前版本正在进行中。 尽管大部分开发工作都投入到当前版本中，但以前版本仍必须偶尔支持 Service Pack 版本、关键修补程序和安全修补程序以及其他更改。
本文探讨一些常见的分支策略，以帮助你做出正确的决策。
与存储库范围的 Git 分支不同，TFVC 分支的范围是路径范围，而不是轻量级。 设置条形图，以便在需要代码或发布隔离时创建分支高，并且仅创建分支。
仅限主
“仅主”策略可以是基于文件夹或主文件夹转换为分支，以启用其他可见性功能。 将更改提交到主分支，并选择使用标签指示开发和发布里程碑。
风险：TFVC 标签的可变性和缺乏历史记录可能会增加更改控制的风险。
从主要唯一分支策略开始， 以战略方式 分支，并采用其他策略，根据需要演变为更复杂的策略。
开发隔离
需要维护和保护稳定的主分支时，可以从主分支对一个或多个开发分支进行分支。 它可实现隔离和并发开发。 工作可以通过功能、组织或临时协作在开发分支中隔离。
主 分支中 可能存在更改。 始终将集成 （FI） 主 分支转发到 开发 分支并解决合并冲突。 然后反向集成 （RI） 更改回到 main。 跨分支保持相同的质量条。 在 开发 上生成和运行生成验证测试（BVT），就像在 主开发时一样。
注意：使用此策略，团队可能会永远保留 开发 分支，这可能会生成大型合并票证历史记录。
功能隔离
功能隔离是开发隔离的特殊派生，允许你从主分支（如图所示）或开发分支对一个或多个功能分支进行分支。
当需要处理特定功能时，创建功能分支可能是个好主意。
保持功能工作的生存期和关联的功能分支生存期较短。 经常从父分支转发集成 （FI） 更改。 仅当满足一些已同意的团队条件（例如完成的定义）时，才能将反向集成（RI）重新集成到父级。 主节点上的功能回滚可能成本高昂，并且可能会重置测试。
发布隔离
发布隔离从 main 引入了一个或多个发布分支。 该策略允许在发布时进行并发发布管理、多个并行发布和代码库快照。
当发布准备好锁定时，是时候为发布创建新的分支了。
从 主转接集成 （FI）。 使用访问权限锁定发布分支，以防止对 发布进行意外修改。 对 发布 分支进行的修补程序和热修补程序可以反向集成（RI）回到 主 分支。
注意：没有分支方案是不可变的，这就是为什么你注意到在发布分支上执行的紧急修补程序的原因。 改进每个策略以满足你的要求，而不会忽视复杂性和相关成本。
服务和发布隔离
服务和发布隔离策略引入了 服务 分支。 此策略允许在发布时对 Service Pack 和基本代码快照进行并发服务管理。
如果需要服务模型供客户升级到下一个主要版本以及每个版本的其他 Service Pack，请使用此策略。
与发布隔离一样，发布准备锁定时会创建 服务 隔离和 发布 分支。 从 主 服务向 服务或 从服务 转 发布进行集成。 锁定 发布 分支以防止修改。 可以在服务分支上完成将来 的服务 更改。
如果需要这种隔离级别，请为后续版本创建新的服务和发布分支。
服务、修补程序、发布隔离
虽然不建议这样做，但可以通过引入其他 修补程序 分支和关联的发布方案来继续改进策略。
此时，你已成功探索了一些常见的 TFVC 分支方案。 可以改进这些功能，或者调查其他策略，例如 功能切换、切换功能，以确定功能在运行时是否可用。
问答
为什么分支应该生存期较短？
通过使分支保持生存期较短，合并冲突将尽可能少。
为什么仅在必要时分支？
若要接受 DevOps，需要依赖于生成、测试和部署的自动化。 更改是 连续、频繁和合并作更具挑战性，因为合并冲突通常需要手动干预。 因此，建议避免分支并依赖于其他策略，例如功能切换。
为什么要删除分支？
目标应该是尽快将 更改恢复为主 ，以缓解长期合并后果。 临时、未使用和丰富的分支会导致团队的混乱和开销。
是否可以跨项目分支代码库？
是的。 不建议这样做，除非团队必须共享源，并且不能共享通用过程。
代码升级策略怎么样？
代码推广策略感觉就像瀑布开发时代的遗物。 它通常具有较长的测试周期，以及单独的开发和测试团队。 不再建议使用此策略。 有关此策略的详细信息，请参阅 分支指南。
将 开发 合并到 主 分支时，为何未检测到任何更改？
例如，你可能忽略了以前合并中的更改，例如，使用 keep source 冲突解决选项。 请参阅 将开发分支合并到主分支：没有更改合并 的详细信息。
TFVC 和 Git 分支策略之间是否存在相似之处？
TFVC 功能隔离分支策略类似于 Git 主题分支。
作者：杰西·侯文、马库斯·费尔南德斯、迈克·富利和威尔·肖布从 ALM |DevOps Rangers。 可以 在此处与他们联系。
（c） 2015 Microsoft公司。 保留所有权利。 本文档提供“as-is”。本文档中表达的信息和视图（包括 URL 和其他 Internet 网站引用）可能会更改而不通知。 你承担使用它的风险。
此文件不会向您提供关于任何Microsoft产品的任何知识产权的法律权利。 可以复制本文档并将其用于内部参考目的。