微软 Office 版本控制从 Source Depot 迁移到 Git 的经验和教训

曾参与 OneNote 开发的微软工程师 Daniel Sada 近日发文，介绍了微软 Office 团队将项目的版本控制系统从 Source Depot 迁移到 Git 的经历。

Source Depot 是微软早期基于 Perforce 开发的版本控制系统，随着 Windows 代码规模的扩大，它逐渐显现出诸多问题，如操作缓慢、分支切换困难、集中化导致网络问题时生产力停滞等，且维护成本高昂，员工也希望能掌握更具通用性的技能。

Office 团队面临着规模与复杂性挑战：Office 团队庞大，约有 4000 名工程师，且服务于不同客户群体，有 LTSC、半年度更新、月度更新、内部测试等不同更新节奏，此外其版本号构成复杂，需保证版本间的一致性及测试验证。

数百名微软工程师耗时数年终于将 Office 项目的版本控制从 Source Depot 迁移到了 Git。四千名工程师工作的 MS Office 办公软件项目切换到了 Git。

迁移过程

• 第一阶段：建立“平行宇宙”：创建一个同步 Source Depot 和 Git 的桥梁，将 Source Depot 的分支层次结构映射到 Git 的 DAG 结构，同时保留提交者信息和时间戳，并确保反向整合和正向整合的一致性。初期尝试失败，经历了三次不同年份的尝试才成功建立稳定的同步服务。

• 第二阶段：验证等效性：对两个代码库运行完整的测试套件，每天进行对比，花费数月时间解决语义差异、行尾处理、大小写敏感和测试输出不匹配等问题，直至实现所有测试在两种系统中完全相同通过。

迁移策略

• 人员沟通与协作：采用“冠军”枢纽辐射模式，每个团队指定一名“冠军”作为联络人，在中心工程团队与各团队间建立桥梁，通过多种渠道反复传达信息，确保重要信息被充分接收。

• 培训与技术支持：为开发者提供培训环境，模拟常见工作流程，创建视频库展示真实开发者解决问题的过程，帮助他们熟悉 Git 操作，消除对出错的担忧。

• 回滚策略：制定明确的回滚策略，赋予领导“红色按钮”权力，可在迁移影响生产力时随时停止，以确保迁移过程可控。

原文：https://danielsada.tech/blog/carreer-part-7-how-office-moved-to-git-and-i-loved-devex/