Git 比大多数人工智能工具都古老.为什么至今还没有人取代它?

2005 年 4 月，Git 向自己的仓库提交了第一份代码。当时，Linux 内核项目失去了专有版本控制工具 BitKeeper 的免费使用权，Linus Torvalds 只好赶紧动手，写出一个替代品。

他需要的东西必须足够快、支持分布式，而且不容易损坏数据。留给他的时间，只有几个星期。

再看看后来发生的事：GitHub 在 2008 年上线，第一代 iPhone 在 2007 年上市。

GitHub Copilot 到了 2021 年才出现，ChatGPT 是 2022 年底的事，而眼下这波编程智能体热潮，也不过是最近两年才兴起。

这些 AI 工具，无论写代码时有多先进，最后都得把成果交给一款比智能手机还早诞生的软件。

放在我们这个行业，这件事本该显得很奇怪。毕竟，前端框架差不多每隔十八个月就要被重新折腾一遍。

Git 还在慢慢调整默认分支名称的时候，我们已经换过包管理器、构建工具，连 Python 工具链都翻新了半套。

那么，为什么偏偏是这个开发者每天都要碰的工具，始终没人能把它拉下王座？

简单的答案是：有人试过，而且不止一拨，最后都输了。更有意思的答案则是，替换其实已经开始了。

只是，它发生在你根本看不到的地方。

一个摆在眼前，却被习以为常的垄断

Stack Overflow 上一次在开发者调查中单独列出版本控制工具，还是 2022 年。当时，96.65% 的专业开发者表示自己使用 Git。

排在第二位的 Subversion，占比不到 6%。软件行业里，很少有技术能拿到这样的份额。而那些做到的技术，比如 TCP/IP、Unix、SQL，往往也会逐渐脱离“工具”的范畴，成为基础设施。

GitHub 自己公布的数据，把这一点衬托得更加明显。

它的 2025 年 Octoverse 报告显示，平台上的开发者已经超过 1.8 亿，仅印度就贡献了约 2,190 万。

一年十亿次提交。而这，还是编程智能体尚未成为许多仓库主要代码作者时的规模。

Git 早已不只是在市场里领先。它几乎就是这个市场本身。

想替换它的人，从来没少过

那些替代品并不差。有些地方，甚至做得更好。

Mercurial 和 Git 在同一个月诞生，命令行更清晰，上手也更温和。Facebook 和 Mozilla 都曾多年押注于它。

它现在仍然存在。但真正让局面定下来的节点，是 2020 年：曾经大力支持它的主要托管平台 Bitbucket，彻底取消了对 Mercurial 的支持。

SQLite 的作者开发了 Fossil，把缺陷跟踪、Wiki 和论坛，全部装进一个文件里。

Pijul 和 Darcs 则建立在补丁的数学理论之上，让合并行为比 Git 的处理方式更容易推断。不少工程师试过之后，都对它们印象不错。

但这些优点，并没有改变结果。因为竞争的关键，早就超出了工具本身，而在于代码究竟放在哪里。

当 GitHub 先成为开源项目的默认落脚点，接着承接求职作品集、CI，再到软件包注册与分发时，选择另一套版本控制系统，就意味着要离开围绕它形成的整套生态。你现成的 CI 模板，默认用的就是 Git。

部署平台，也默认你使用 Git。

新同事熟悉的操作，还是 Git。就连你的 AI 编程智能体，都见过数以百万计的 git rebase 示例，却几乎没见过几次 pijul record。

工具做得更好，并不足以打败一个更强的生态。过去二十年的版本控制竞争，一次次证明了这一点。

真正站住脚的工具，都学会了兼容 Git

看看 2026 年那些真正开始获得关注的挑战者，你会发现一个共同点。

它们都没有要求你离开 Git，而是建立在 Git 之上。

Jujutsu，通常简称为 jj，最初是 Google 工程师 Martin von Zweigbergk 的业余项目。

它取消了暂存区，把工作副本视为一个提交，记录每一次操作，让你几乎什么都能撤销；甚至允许冲突留在历史里，等你准备好了再处理。

这是一套明显不同的思维方式。但它使用 Git 自己的磁盘存储格式，读写同一个 .git 文件夹，生成的也仍然是普通 Git 提交。

你的队友，甚至不用知道你已经换了工具。

Meta 在 2022 年底开源的 Sapling，也走了类似的路线。

它提供新的客户端、新的工作流程，但从第一天起，就能对接 Git 仓库和 GitHub 的 Pull Request。

这才是 Git 一直留在原位的重要原因。它早就超出了一款程序的范围。

它是一种文件格式，也是一套通信协议。代码托管平台、CI 系统、IDE 和 AI 智能体，全都同意用这套方式交流。

你可以换掉自己敲命令时使用的程序。但要替换其他所有系统彼此沟通的语言，就没那么容易了。

后来，还真有人把 Git 换掉了

10 月 13 日，Anthropic 发布了一篇工程文章，解释它如何让内部单体仓库彻底离开 Git，迁移到一套自行开发、名叫 Scion 的系统。

原因并不是 Git 设计得不好，而是智能体带来的规模变化。Anthropic 表示，2026 年 5 月，它平均每天合并约 2,500 次代码变更；到了 9 月，这个数字已经超过 30,000。

主分支的历史数据膨胀到接近 100 GB。光是 CI 系统，每天就要执行约 2,500 万次检出。

高峰时期，公司需要运行数百个 Git 镜像才能跟上需求，而这些镜像本身，又逐渐成了新的运维负担。

Scion 改变了 Git 最初的一项基本假设。Git 面向的是拿着笔记本电脑、随时可能离线的人类开发者，因此，常规完整克隆会携带整套历史记录。

但 Anthropic 工作量最大的“开发者”是 Claude，它始终在线。于是，Scion 把提交、合并、变基、代码归属追踪，也就是 blame，以及历史记录都放到服务端处理，客户端只保留一份有大小限制的本地缓存，缓存自己真正需要的文件。

过去需要几分钟的检出，现在几秒就能完成。

有意思的转折来了。Simon Willison 读完文章后指出，Scion 听起来像是“沿着 Subversion 的路线，重新发明了一套集中式版本控制系统”。

他说得没错。二十年来，第一个真正大规模替换 Git 的方案，运行起来反倒很像当年被 Git 取代的那类工具。

而且，Anthropic 并不打算把它提供给其他人，也不会开源。

公司自己的文章明确表示，Scion “绝不是适合通用场景的 Git 替代品”。它只适用于超大型单体仓库，或者智能体工作负载极重的环境。

第一家真正替换 Git 的公司，得先自己开发代码审查工具、CI 集成和代码搜索，才撑得住这次迁移。这，才是离开 Git 的真实代价。

Git 留在原地，谁最受益？

把 Scion 的故事和 2026 年其他版本控制新闻放在一起看，一条共同的路线就浮现出来了。

7 月，Jujutsu 的创造者 von Zweigbergk，成为初创公司 East River Source Control 的首席技术官。

这家公司的判断是，jj 这样的工具已经改善了本地使用体验，但远端服务器运行的仍然是 Git。因此，ERSC 正在为服务端打造一套新的存储层。

6 月，一个叫 Oak 的项目出现在 Hacker News 上，宣称要为 AI 智能体设计版本控制：支持虚拟挂载，每个任务一个分支，并以中心服务作为权威数据源。

需要的时候，它也能导出为 Git。

这些认真做替代方案的项目，都把重点放在了服务端。它们并没有把主要精力放在你终端里的那套命令上。

这已经说明，真正的成本和痛点在哪里。对一个独立开发者来说，Git 用起来没有什么大问题。

但对每天要处理数百万次智能体检出的平台而言，Git 那套“每个人都拿一份完整副本”的模式，运行成本就相当高了。

因此，更可能出现的未来，是你仍然继续输入 git。

只是，git 逐渐成了一层兼容接口：你在本机使用熟悉的命令，连接的服务器内部，却早已换成另一套工作方式。

GitHub 和 GitLab 可以保留那套将生态与平台紧密绑定的协议，同时悄悄重建背后的系统。

Anthropic 的文章，差不多就是在建议它们这么做：让更多操作在服务端执行，并改进稀疏检出。

Git 自己也在变化，只是步子比较慢。

项目文档中的 Git 3.0 计划，包括让新仓库使用 SHA-256 哈希，默认采用更新的 reftable 格式存储引用，把默认分支命名为 main，并将 Rust 纳入构建时的必需依赖。

目前仍然没有发布日期。对于一款嵌入如此之深的工具，这样的节奏，本身也有价值。

越是这种无聊工具，越该认真学

如果你是学生，或者刚入行的开发者，看着 AI 智能体接手越来越多的编码工作，很容易觉得：Git 不就是那点杂活吗？交给智能体处理就行了。我觉得，这个想法恰好反了。

智能体写的代码越多，你的工作就越会转向审查、合并、理清混乱，以及出错后的恢复。

这些都是 Git 的活。看懂提交图，用 git bisect 找出导致生产故障的那次改动，用 git reflog 救回一次搞砸的变基，或者给每个智能体分配独立的 git worktree，避免它们互相干扰——这些能力的价值，正在上升。

甚至围绕 Scion 的讨论，最后给普通团队的建议，也还是落回了 Git 原有的功能：使用稀疏检出，以及为每个智能体配置一个独立的 worktree。

Git 一直没被取代，因为它早就从工具变成了一门语言。这样的语言，不会轻易退场。

它会迎来新的使用者、新的表达习惯，以及背后不断更换的技术系统。

Anthropic 刚刚证明，你确实可以离开 Git；但紧接着，它又告诉其他人，没必要跟着折腾。

一款软件走过二十一年，还能得到这样的评价，大概已经是极有分量的认可了。