5个月自研版本控制系统：如何支撑日均3万次代码合并

一家公司在五个月内从零构建了全新的版本控制系统，并把整个单体仓库从Git完整迁移过去。驱动这一决策的，是一个近乎疯狂的数字变化：代码合并量在几个月内从日均约2,500次飙升到超过30,000次。

这不是一次常规的基础设施升级，而是被AI编程代理逼出来的架构重构。当写代码的主体从人变成代理，为人类开发者设计的工具链开始集体失效。

从2,500到30,000：代理规模压垮了人类尺度的工具

据该公司工程博客披露，5月时他们每天合并约2,500次代码变更，到9月这个数字变成了每天超过30,000次——增长超过十倍。

这个量级的变化并非来自团队人数扩张，而是AI代理大规模参与编码的结果。代理提交变更的频率、并行度和持续性都远超人类开发者，传统开发基础设施在这种压力下迅速成为瓶颈。

关键问题不在于Git本身“坏了”，而在于它被设计时预设的使用者是人类：合并节奏、冲突处理、仓库操作的延迟假设，都建立在人类操作速度之上。当代理以机器速度持续提交时，这些假设逐一崩塌。

“代码合并”（merge）指的是把一条分支上的变更整合进主干或其他分支的操作。在 Git 工作流中，一次合并往往伴随代码审查、CI 触发、冲突解决等一连串动作，因此合并频次是衡量开发基础设施负载的直观指标。日均 2,500 次合并对应的是数百名开发者以人类节奏提交变更的典型规模；而 30,000 次则意味着平均每几秒就有一次合并发生，仓库锁竞争、引用更新、流水线排队等环节都会被放大到不可忽视的程度。理解这一量级差异，是判断瓶颈究竟出在“配置调优”还是“架构前提”的关键。

为什么选择自研，而不是继续优化Git

面对瓶颈，常规做法是优化现有Git工作流、增加缓存层或拆分仓库。但这家公司选择了更激进的路径：自建一套版本控制系统。

这个决策的隐含判断是，Git的架构与代理规模的工作负载之间存在根本性错配，局部优化无法解决。原文没有展开具体的技术瓶颈细节，但从“为人类而非代理规模构建”这一表述可以看出，问题出在设计前提层面，而非配置层面。

另一个值得注意的细节是迁移范围：整个单体仓库（monorepo）从Git完整迁出。单体仓库通常承载着公司几乎全部代码和历史，迁移它意味着要处理海量历史数据、所有工具链集成以及全体开发者的工作流切换。

单体仓库（monorepo）指把公司多个项目、服务乃至全部代码放在同一个版本库中管理。它带来跨项目统一依赖、原子化重构和统一工具链的好处，但也把版本控制系统的性能、可靠性和迁移成本集中到一个点上。迁移一个成熟 monorepo 不只是复制提交历史，还涉及挂钩（hooks）、权限模型、CI 触发规则、代码搜索索引以及开发者本地工作流的同步切换。一旦新系统在合并吞吐或历史查询上出现退化，影响面会覆盖全体工程师，这也是此类迁移通常被视为高风险项目的原因。

五个月完成自研与全量迁移

从决策到落地，整个过程只用了五个月，包含两个阶段：构建新版本控制系统，以及把单体仓库从Git完整迁移过去。

这个时间跨度值得单独拿出来说。自研版本控制系统本身就是一项重量级工程，而全量迁移单体仓库通常被视作高风险、长周期的项目。五个月同时完成两件事，说明团队在范围控制上做了明确取舍，也可能是代理规模的压力迫使他们必须以极高速度推进。

原文并未披露新系统的具体架构、存储模型或与Git的兼容策略，因此无法判断其技术路线是全新设计还是在Git基础上做深度改造。这是该案例目前信息中最大的空白。

CI/CD（持续集成/持续交付）流水线通常由代码合并事件触发：每次合并都会拉起构建、测试与部署任务。当合并频次从日均数千跃升到数万，流水线的并发调度、构建缓存命中率和测试资源分配都会承受与版本控制同等量级的压力。因此，即便新的版本控制系统解决了合并吞吐问题，下游的 CI 编排与测试执行仍可能成为新的瓶颈。该案例提示，代理规模带来的负载是端到端的，任何单点优化都需要放在整条工具链中评估。

对开发基础设施的启示

这个案例的价值不在于“又一家公司自研了基础设施”，而在于它揭示了一个正在扩散的趋势：AI代理正在改变开发工具的使用者模型。

当代码提交的主体从人变成代理，一系列基础设施假设都需要重新审视——不只是版本控制，还包括CI/CD流水线、代码审查流程、测试资源调度等。这家公司的合并量十倍增长是一个先行信号，类似压力可能会出现在更多重度使用AI编程的团队中。

对多数团队而言，自研版本控制系统并不现实，但这个案例提出了一个更现实的问题：现有工具链中，哪些环节的假设正在被代理规模悄悄打破？识别这些瓶颈，比照搬激进方案更有价值。