版本控制的复兴

# 版本控制的第二次爆发 来源：https://psantosl.github.io/posts/version-control-second-coming/ 2005年初夏，就在我们为Plastic SCM签下首位天使投资人的同一周，林纳斯·托瓦兹宣布了Git的诞生。我花了超过一年时间向投资者推介构建全新版本控制系统的计划，而Linux的缔造者竟亲自操刀。那一周我明白，前方的路将比想象中更为艰难。 二十年间，我再未感受过那种触电般的震撼。直到几个月前。 当2025年12月左右我们几乎停止手动编写代码时，另一股变革正在酝酿：自2005年以来版本控制领域最重大的革命。两股力量同步涌动：智能体带来的超高频率提交需求，以及取代GitHub的迫切渴望。本文将剖析这两大驱动力，并展望版本控制在适应与支持新型软件开发模式的过程中，可能为未来带来的变革。 提前声明：我绝非中立者。我曾用Plastic SCM与Git竞争二十年，为动视暴雪的巨型单体仓库提供咨询约两年，现正为Diversion担任顾问，并在Origin致力于让Git实现前所未有的性能突破——因此我从擂台的每个角落见证过这场战役。 ## 巨头的衰落 若在两年前预言GitHub将迅速式微，无人会信。曾几何时，GitHub是代码托管领域无可争议的领导者，更深刻塑造了开发者对版本控制的认知。作为竞争对手（后文详述）的那些年，我深有体会：任何与“GitHub方式”相悖的设计都会被视作错误。GitHub至今仍在仓库数量与用户心智中占据庞大版图，对软件开发与协作生态的影响深远，且很可能持续。但经历足够多技术周期的人或许记得，曾有个时代无人敢看衰SourceForge，而仅数年后，随着GitHub崛起，它已近乎被遗忘。我们是否正处在类似的转折点？GitHub多年来的卓越成就令我期盼它能延续辉煌，但地震确已发生。 ## 我的版本控制生涯 若你读到此文，很可能知晓我在2005年联合创立了非Git系的Plastic SCM。这款专注于高性能与海量仓库的工具，后于2020年被Unity收购。但我使用的首款版本控制工具是2000年首份工作时的Visual Source Safe。这款俗称VSS的工具虽饱受诟病，但事后看来它也有精妙之处：极简的设计与便捷的跨项目文件共享（这点或许仍未被完美解决）。数月后我加入索尼比利时分公司从事数字电视开发，得以接触已被IBM收购的ClearCase。初时震惊，随后叹服——它拥有卓越的分支合并能力、虚拟文件系统，且架构极度灵活。我主要在Sun工作站使用它，庆幸当年未接触其“简化版”（我认为这加速了其消亡，因它阉割了核心能力）。ClearCase昂贵得惊人，记忆中企业级授权约每年每用户5千美元。版本控制的狂热就此点燃。何不打造兼具ClearCase强大功能与普惠价格的工具？于是我研习Subversion、CVS乃至Perforce（至今仍是众多大型游戏与芯片团队的首选）。2005年夏，在耗费年余撰写商业计划书游说投资者后，Plastic SCM正式创立。此后我亲历了众多版本控制系统的兴衰：与AccuRev屡次交锋（其卓越方案现已式微），见证微软Team Foundation Server、IBM Jazz（试图取代ClearCase）、Serena等产品的沉浮，许多名字已渐被遗忘。 ## 2005年：最后一次大爆发 约2005年，一场争夺Linux内核版本控制权的竞赛悄然展开。BitKeeper亟待更替（其本身就是传奇故事），Mercurial、Darcs等系统竞相角逐桂冠。坦白说，当Plastic SCM萌芽时，为Linux内核提供版本控制也是我的梦想。这个愿景在脑海中无比美好，却未曾料及商业产品绝无可能被接纳。或许唯有天真者才会开创全新版本控制系统。随后Git入场——那个震动我的夏日宣言——并最终胜出。这是场革命，而约2008年GitHub的诞生使其走向大众，余下皆成历史。彼时涌现的新系统令人惊叹，Git与Mercurial或许成为采纳最广的两大体系。 ## 第二次爆发 2025年末，我有幸与多个开发新型版本控制解决方案的团队交流。部分是旧识，部分是新友，但我逐渐察觉暗流涌动。无人敢直接挑战GitHub霸权，但初创企业正四处尝试打造“下一代GitHub”。我确信会遗漏许多重要项目，但以下是我最为关注的几家： **Entire** 当GitHub前CEO托马斯·多姆克为其新创公司——基于Git的版本控制系统——宣布巨额种子轮融资时，业界哗然。他们发布了*来源追踪*功能，可精准识别代码由哪个智能体、通过何种提示生成，这我认为将成为版本控制的标配；同时通过全球分布式副本实现了极速克隆等性能突破。 **Pierre** 访问其官网本身就是独特体验（不知能持续多久），因其设计迥异。Pierre开源了改进的差异比较与文件树工具，赋能各类代码界面，并聚焦code.storage——为智能体时代打造的Git铸造厂。GitHub在面对提交量、拉取请求与流量爆炸式增长时已触及性能瓶颈，而code.storage定位于为所有平台提供底层仓库支持，以满足AI规模需求。近期其X平台帖文揭示Lovable等大型AI方案正依托该系统管理仓库。这无疑是当下最具潜力的Git解决方案之一。 **Origin** 虽是我最后听闻的项目，但其出现让我确信行业正在剧变。Cursor（现SpaceXAI）竟在打造自有Git铸造厂？令人振奋。Origin同样是全功能Git平台，提供拉取请求、仓库托管等完整方案，且目前专注于性能与可靠性。但如同所有Git平台，这仅是激动人心旅程的起点。我的同事兼好友Vmg发表了关于Origin内核技术的精彩文章（https://cursor.com/blog/git-at-any-scale），引发了X平台上持续数周的“WAL S3”讨论。Scott Chacon与Tobias Lütke等人受其启发，数日内便实现了各自的版本。这正是我数月前加入的团队，如前所述，我全职回归版本控制内核开发——请据此理解我的热忱。此次我不再与Git竞速，而是致力于将其推向性能极限。 **GitButler** Scott Chacon的新版本控制项目已运营数年，现定位为“智能体的版本控制工具”，延续了同一趋势但路径不同。GitButler并非*新铸造厂*，而是聚焦客户端，提供截然不同的用户体验概念与性能优化。其堆叠分支（我认为皆有需求）、改进的变基操作，以及诸如“虚拟分支”等创新理念，使其成为Git演进前沿的代表。 **East River Source Control** https://ersc.io/ 名单中首个非Git系项目...其围绕Jujutsu构建。我曾数次与Google版本控制团队交流（每次对话都令人享受，他们在超大型单体仓库等领域的造诣极高），他们引荐了这支将Jujutsu推向市场的团队。Jujutsu由Google的Martin von Zweigbergk（我有幸与之结识）发起，旨在成为Git的继任者。它引入堆叠分支等创新概念，更支持对仓库中未解决冲突进行版本管理，开启了前所未有的可能性。重组提交、重叠应用变更（纯粹堆叠）成为全新体验。Jujutsu可基于Git运行，但Google内部采用独立后端，ersc正尝试将此理念商业化。推送至GitHub时会丧失部分Jujutsu的额外能力，而原生后端将改变这一点。我期待Jujutsu生态持续进化，无论采用原生形式、移植至Git还是其他版本控制系统。 **Diversion** 作为顾问，我已与Diversion合作逾三年。这家非Git系的初创公司运营数年，其理念令我忆起Plastic SCM岁月——曾以截然不同的技术栈四处与Git较量。但他们的方式独具特色，我认为这使其在“版本控制革命”中至关重要：诞生于后去中心化时代。我曾痴迷于推送/拉取远程仓库的模式，实际上Plastic 2.0或3.0（约2008年）已实现分布式架构，可兼容集中式（SVN风格）与分布式，在同一仓库中按需融合。我痴迷于这种灵活性。但分布式模式虽卓越，却源自不同世界。如今网络已无处不在，甚至飞机上也能稳定连接。坚持本地提交再推送有何意义？Diversion聚焦大型仓库（这与我过去研究相同），我发现这是游戏开发者的关键需求。游戏团队常需处理超1TB、含数百万文件的仓库。此规模下维护本地克隆根本不可行。“提交后推送”模式在诸多专业环境中更是效率瓶颈，许多团队只求直连集中式服务器提交。这正是Diversion的强项，但不能将其视为“回归Subversion时代”，因其性能更卓越、全面云部署、出色的分支合并（Git真正沉淀的精华）等功能俱全。Diversion引入云优先工作区，完全在服务器端进行版本管理，开启了新型协作可能，虽模式不同，却与Jujutsu的能力颇有相通之处。 **Oxen.ai** 目前从其官网较难看出这是为大型AI数据集提供版本控制的平台。我最初接触他们是为动视暴雪提供版本控制咨询时，因其若能处理海量数据集，游戏场景管理便不成问题。我曾与创始团队会面，真心喜欢其*亲和*架构（大量极速底层操作保障系统高效）。Oxen不参与其他项目的“铸造厂竞赛”，但它是市场演进超越过去二十年的重要例证。 **Lore!** 为延续这种兴奋感，Epic Games甚至开源了其版本控制系统Lore，瞄准大型单体仓库与游戏行业。这款不基于Git的全栈解决方案极具差异性与吸引力。它采用类似Git的底层有向无环图，优化了大型二进制处理，基于现代算法实现数据传输优化（仅更新变更部分，避免无效下载）...虽看似集中式架构，却支持断网工作。 ## 未来展望 我在分析Diversion时已部分提及，因为我深信团队将面临的挑战包括：需处理超高频率提交的大型单体仓库。当微软试图将Git引入Office团队时，首先开发虚拟文件系统（这正是我推崇的方案类型）以对抗Git的分布式特性（大型仓库中的缺陷）。文件数量达千万级时，Git常规布局捉襟见肘。他们最终放弃VFS，转而推出“git scalar”，现已成为大型仓库管理利器。 ## （超）大型单体仓库解决方案 我不确定众多Git铸造厂是否会朝此方向演进，但每秒接收海量贡献的大型单体仓库必将成为未来版本控制的关键领域。或许我们会看到演进的Git覆盖此需求（若基础架构无法适配则形态将截然不同），或出现完全不同的技术栈（Diversion、Lore、Oxen？）。 ## 分布式模式的式微 我的判断是，采用推送/拉取而非直接提交的分布式模式将受限于仓库规模。超过某个阈值（可能300GB+仓库与百万文件），行业将需借鉴非Git版本控制系统的现有方案。我预见AI或可平滑实现Git的定制分支以解决部分问题，若行业未勇敢采纳全新范式，两三年后的“Git”或将与今日的我们认知大相径庭。 ## 超高速提交 目前在Git铸造厂向主分支提交需序列化处理，因此存在速度上限。Google多年前以内部Piper系统突破此限制（这也是Jujutsu在Google内部对接的后端，而非我们外部使用的Git后端），我认为将有更多方案重新探索这一理念。 ## 虚拟文件系统普及 这更近梦想而非预测，因为我渴望这样的工作流：通过全虚拟文件系统按需从单体仓库加载所需文件，本地以近乎零成本（写时复制）生成无限仓库副本，极大提升可用性与体验。25年前ClearCase（在我心中是版本控制领域的施乐帕洛阿尔托研究中心）首次展现此理念，我为Plastic开发过相关版本，并目睹其被行业巨头与众多大型游戏公司采用。但实现存在障碍：首先是macOS，其架构使高性能虚拟文件系统开发异常困难（我在Linux与Windows上的实验性能卓越，但macOS上无解）；其次，智能体或可屏蔽底层复杂性，使我们不再关注...但速度与磁盘占用仍至关重要。 ## 二十年来最佳时代 2005年，十余款版本控制系统争夺BitKeeper的继任者地位，最终胜者主导软件开发长达二十年。当年竞赛中无人预见，决定性因素将是一个托管网站...