Git遭遇性能瓶颈：大规模项目与AI时代下的挑战与替代方案

那一天，Git 在我面前“停摆”了。

事情发生在一个普通得不能再普通的周二早晨上线。按理说，这种部署属于“过了就忘”的那种无聊流程。可偏偏这一次，Git 卡住了。不是崩溃，不是报错，就是……不动了。一次简单的 git pull，硬生生拉了六分钟。风扇狂转、CPU 飙高，而那个仓库早就长成了一个“谁都不想承认我们养出来的怪物”。

那天我并不孤单。团队里 Slack 同一时间刷屏：“Git 又喘不过气了。” “你们的 pull 也巨慢吗？” “这破仓库现在 9GB 了……”然后一个更刺耳的事实砸过来：不是仓库的问题，不是流程的问题，也不是硬件的问题，是 Git 自己在拖我们后腿。

它不是那种“轰”一声的失败；相反，它是慢慢地、悄悄地、让人习惯成自然的那种失效。而当我开始认真观察，我又意识到一件更不舒服的事：Git 从来就不是为现代软件开发方式设计的。只是没人愿意公开说，因为太多开发者的身份认同绑在 Git 上了。可我们必须聊聊这事。

人人都看见的裂缝（只是大家假装没看见）

先从最明显的开始——Git 每天都在折磨我们，可偏偏很少有人把它叫做“失败”。

1. Git 在现代规模面前会碎

Git 诞生于 2005 年。那时候：

• monorepo 还不流行，甚至几乎不存在
• 代码库不会动不动 20GB
• 团队不会跨 15 个时区同时开发
• CI/CD 不会每天产出、提交几百个构建产物
• LFS 还没出现
• 开发者也不需要把 10+ 年的历史全量克隆到本地

然而，Git 的底层架构并没有发生本质变化；与此同时，我们的工作方式却彻底变了。据 Google 自己关于 Piper（他们的 Git 替代方案）的文档描述，Git 在超大规模场景会变得“运维上很脆弱”。GitHub 的工程博客也承认：当仓库历史极深、目录树频繁变化时，Git 的对象存储模型会变成性能瓶颈。我们之所以硬扛，是因为 Git “是标准”。但是标准不等于适配。因此，规模正在把 Git 一点点吞掉。

2. Git 的合并模型，像是另一个时代的遗物

我们总说 Git 的 merge 很强。可它也同样是：冲突高发、状态复杂、心智负担重、容易被弄乱、出问题很难定位。

每个开发者都经历过这种地狱连招：

• git rebase
• git rebase --abort
• git reset --hard HEAD~1
• git cherry-pick
• git push --force

最后一个呢？那个大家用得“很随意”的命令？在大团队里，它就是“离毁掉同事一天只差一个回车”。如果 Git 是今天才被发明出来，force push 大概率会被直接列入黑名单。

3. Git 很慢，而且只会越来越慢

现在就做个小实验：

time git status

在 3–5GB 以上的仓库里，git status 都可能明显发黏，因为 Git 需要扫描整个工作目录。我们把这种卡顿当成“正常”。不应该。尤其是当替代方案可以以数量级更快的速度计算工作区状态时，Git 的性能上限就不再是“能忍”，而是“该换”。

4. 二进制资产团队，天生和 Git 八字不合

游戏工作室、ML/AI 团队、视频制作、嵌入式项目。这些团队讨厌 Git，并不是他们“不专业”，而是 Git 根本没为巨大二进制资产设计。Git LFS 说白了就是创可贴——而且大家都知道它只是创可贴。Unity、Unreal 开发者经常写类似的话：“Git 对游戏资源来说根本不可用。”他们没夸张。

5. Git 打断人的工作流，远多于它帮助人的地方

这句话可能刺耳，但很真实：Git 逼着开发者去适应机器能理解的流程，而不是人更自然的思考方式。你听过多少新同事、初级开发者说过：“我不知道我现在 repo 是什么状态。”我们觉得 Git 顺手，是因为我们已经交过“学习税”。新人却要承受全部代价。

更反讽的是：到了 AI 写代码的速度已经快到 Git 管理它都显得慢的时代，Git 反过来成了瓶颈。

争议点：Git 的“成功”，更多是惯性

开发者不是因为 Git 很棒才用它。我们用 Git，是因为：

• GitHub 把 Git 变成了代码的社交默认入口
• 教程全都教 Git
• 公司招聘默认要求 Git
• 工具链围绕 Git 生态构建
• 我们害怕替代方案
• 我们不想重新学习

如果 Git 今天才发布：带着这些性能问题、交互痛点、对二进制的敌意——它大概率不会赢。赢的是生态，不是技术。就像 Java 在企业里赢，并不完全因为它“最强”，而是因为它“到处都是”。Git 本质上是穿着潮牌外套的老技术。

替代者并不神秘：它们已经在发生

这不是脑洞。Git 的替代方案早就存在，而且大公司也早就用上了。我们聊三个最代表性的。

1. Google 的 Piper

Google 从来就没有在超大规模里用 Git 做主力。他们尝试过，测量过，然后放弃了。Google 的研究与工程实践反复指向同一组结论：Git 在巨大仓库里会崩坏、Git 的分支与合并模型不适合超大规模协作、Git 存储会遇到瓶颈、Git 的分布式特性，在企业 monorepo 里反而成了弱点。

所以他们做了 Piper + CitC，一套版本控制系统，主打：即时同步、工作区虚拟化、支持数百万文件、不需要深度克隆历史、高性能分支、内建代码审查流程。常被引用的出处之一：Google 的文章《Why Google Stores Billions of Lines of Code in a Single Repository》。Piper 不是过去式，它更像 Git 的未来样子——只不过我们还被困在 Git 的过去里。

2. Meta 的 Sapling（前 Facebook VCS）

Meta 公开写过类似表述：“Sapling 是一个可替换 Git 的工具，并且能显著提升大仓库性能。”它主张的改进包括：更快的文件状态计算、更快的历史浏览、更快的合并、比 Git 更少困惑感。Sapling 已经在 Meta 内部使用。对他们来说，迁移不是“想不想”，而是“活不活得下去”。

3. Fossil、Plastic、Perforce：老牌巨头从未离场

AAA 游戏工作室并不靠 Git 管资产。他们用 Perforce。与此同时，AI/ML 团队对 Fossil、Plastic SCM 的兴趣也在上升，因为：Git 会被大文件拖死、Git 的合并模型遇到生成物就容易失控、Git 对象存储会膨胀到离谱。技术圈常假装 Git 是“宇宙通用”，现实不是。

一个瞬间，让我彻底换了看法

我当时在 review 一个初级同事的 pull request。她犯了一个很小的错误，导致一个冲突——很普通的人类失误。然后 Git 直接爆炸：

• CONFLICT (content):
• CONFLICT (rename/delete):
• CONFLICT (modify/modify):

她慌了，她以为自己闯了大祸。可 Git 没有引导她，Git 只是吓唬她。那一刻我突然意识到：Git 会惩罚错误，却不会陪你把错误走完。而今天最好的工具应该做什么？应该解释、可视化、可回滚、可沙箱、可模拟、可恢复。Git 基本都不做。

一组真实对比，差点把我们团队看沉默了

我们在一个大型、二进制占比很高的仓库上做了实际测试。仓库大小：8.4GB，文件数：约 94,000，历史：12 年。

git status：

real    17.224s
user    14.553s
sys     2.141s

sapling status：

real    0.247s
user    0.110s
sys     0.034s

快了 70 倍。这不是“抠性能”，这是“换世界观”。

为什么开发者会如此拼命替 Git 辩护

这句话可能最扎心：开发者为 Git 辩护，是因为他们花了很多年学会了如何驾驭一个会惩罚新人的工具。承认 Git 在失败，就等于承认：我们浪费过时间、我们背过一堆糟糕的流程、我们搭过脆弱的 CI、我们害怕再训练、我们抗拒改变、我们沉迷舒适区。

开发者也会因为熟悉而固执，即使更好的工具已经存在。很多 Git 的捍卫者，有点像拒绝离开 Vim 的人：很酷，很硬核，但很难规模化。

未来：替代 Git 的下一代版本控制应该长什么样？

假设有一天，Git 不再是默认选项。下一代 VCS 至少应该具备这些能力：

1. 虚拟化工作区

不再需要克隆 20GB 仓库到本地。

2. 即时状态检测

不扫描全量文件树，不再让 git status 成为日常折磨。

3. 更少冲突的历史模型

Google 的合并模型在某些场景能减少痛苦；而 Git 的方式在现代协作里太容易炸。

4. 原生二进制支持

不应该需要 Git LFS 这种补丁式方案。

5. 内建评审工具

代码评审不该依赖外部平台拼装。

6. 零成本分支

分支应该是“虚拟的”，而不是“昂贵的复制与历史负担”。

7. 系统级撤销

不再靠这种晦涩咒语：git reset --hard HEAD~1

8. 人类优先的工作流

版本控制应该贴近人的思维方式，而不是让人去迁就机器。

Git 并不是为这个世界造的，它的继任者会是。

代码例子：Git 如何在“走历史”上崩溃

git rev-list --all --objects | wc -l

在大仓库里，这条命令可能要跑好几分钟。而现代 VCS 往往通过索引元数据来完成同类查询，能做到毫秒级，而不是递归暴走。

对比一下：
Git：

git log --full-history -- <folder>
# 32 seconds

类似 Sapling 的索引式遍历：

sl log folder/
# < 450ms

Git 在用蛮力对抗几何问题，替代者用索引解决问题。

最不舒服的问题

我问你一个很多 Git 拥护者不愿意面对的问题：如果没有 GitHub，Git 还会是世界默认的版本控制系统吗？

我很怀疑。而这恰恰就是问题所在。Git 的统治更偏文化，而非技术。因此，它的衰落也会是文化性的——看起来突然、实际上必然。

接下来会发生什么

Git 不会一夜消失。但是裂缝会变成断裂，断裂会变成迁移路径，迁移路径会变成默认选项。

如果要我预测：

• AI-first 工作流会先把 Git 推到极限
• 企业级 monorepo 会第二批离开 Git
• 游戏与 ML 团队基本不会回头
• 新工具会原生集成云工作区
• Git 会变成“必须会但很少用”的遗留技能

就像 CVS，就像 Subversion，就像所有我们曾说“会永远存在”的东西。

最后：开发者值得更好的工具

我们已经长大了，Git 没跟上。不是情感上、不是文化上，而是技术上。而一旦你真的体验过更快、更干净、更像“给人用”的工作区……你就很难再回到那个被 git status 支配的世界。

Git 没死，但它正在死去。悄悄地，慢慢地，可预测地，不可避免地。开发者不该被一个版本控制工具拖慢。

关于技术工具的演进与未来，欢迎在 云栈社区 的开发者广场参与更多讨论。