4000工程师的挑战：Office如何完成版本控制大迁徙

数码芝华士

科技媒体 danielsada 于 6 月 10 日发布博文，报道称微软 Office 团队历时多年，版本控制系统从传统的 Source Depot 迁移到更现代的 Git。

IT之家援引博文介绍，微软在 2000 年初期，面临版本控制的困境，当时 Git 尚未诞生，SVN 也未成熟，于是基于 Perforce 技术，开发了内部系统 Source Depot。

Source Depot 随后撑起了数百万行代码的版本管理，但使用体验却异常笨拙。获取 Office 代码库（repo）需数小时，分支操作复杂如“仪式”，合并变更（Reverse Integrate 和 Forward Integrate）更是令人头疼。一旦网络中断，生产力直接停摆。

Source Depot 虽可靠，却逐渐显露老态，维护成本高昂，员工也抱怨缺乏行业通用技能，迁移 Git 成为必然。

Office 的迁移并非简单切换工具，而是涉及 4000 多名工程师、多个产品线（如 Word、Excel、OneNote）的庞大工程。

不同客户更新周期（如 LTSC 每 6 个月、半年度、月度更新）要求新旧系统并行数月，确保版本一致性（如 16.0.18730.20186）。

此外，Office 代码库规模惊人，单次克隆（clone）需 200GB 空间，常规 Git 操作如状态检查（git status）甚至会超时。为此，微软与 GitHub 联合开发 VFS for Git，仅在需要时下载文件来提升效率。

迁移采用“平行宇宙”策略，即 Source Depot 与 Git 代码库持续同步，确保不中断开发。这一过程耗时长且复杂，需多次尝试以映射两种系统的分支模型和提交历史。