很多人以为 Git 问题最多就是 rebase 写错、冲突没解好、分支管理混乱。

但仓库一大，CI 一密，历史一长，问题会变味：clone 慢、fetch 慢、状态检查慢、历史遍历慢。到这一步，背锅的不该只是命令行。

Ted Nyman 发布了《High Performance Git》First Edition，站点是 gitperf.com，授权为 CC BY-SA 4.0。它值得写，不是因为 Git 又多了一本书，而是因为它把 Git 放回了它本来的位置：工程基础设施。

这本书讲的是 Git 为什么慢

《High Performance Git》覆盖的东西很底层：objects、refs、index、history traversal、packfiles、maintenance、sparse-checkout / sparse-index、partial clone、Protocol v2、reftable，以及 diagnosis / recovery。

这些词看着不像入门教程。也确实不是。

普通 Git 教程解决的是“这条命令怎么用”。这本书更关心三件事：慢在哪一层，为什么会慢，怎么定位和治理。

对比项普通 Git 教程《High Performance Git》
核心目标教常用命令解释性能成本
主要问题怎么提交、合并、回滚为什么 clone、fetch、status、log 会慢
关注层级使用姿势objects、index、refs、packfile、协议和维护
典型读者Git 初学者、普通开发者Build / CI 工程师、DevEx 团队、monorepo 维护者
使用场景个人开发效率大仓库治理、排障、传输优化、维护策略

所以别把它当成“Git 入门第一本”。它更像维修手册。

适合谁？最直接是两类人。

一类是 build / CI 工程师。你们关心的是每次流水线拉代码要花多久，缓存是否有效，网络传输有没有被无谓放大。

另一类是 monorepo 和开发者体验团队。你们关心的是仓库越长越大以后，普通开发者打开、检出、搜索、切分支的成本会不会失控。

如果只是个人项目，仓库不大，历史不复杂，这本书未必立刻改变你的工作流。它的价值在规模到来之后才会显出来。

Git 性能债，会被 CI 和 AI agent 放大

我更在意的是发布时间背后的现实：Git 性能问题正在从少数人的洁癖，变成团队的基础设施债。

过去 Git 慢一点，开发者等一等。今天不一样。

CI 会频繁 clone / fetch。monorepo 会把文件数量和历史长度推高。AI agent 又开始在代码库里反复读、搜、改、跑测试。一次低效操作，放到自动化系统里，就可能变成一串账单。

这不是“Git 老了”四个字能解释的。

Git 本身同时像内容寻址数据库、文件系统索引、图遍历器和传输协议。objects、refs、index、packfiles、网络、维护策略，哪一层松了，都会拖慢上层体验。

真正危险的是团队还把 Git 当个人技能管。

会用 Git，和能让 Git 在几百人、上千次任务、巨型仓库里稳定运行，是两回事。前者靠记命令。后者靠制度。

具体到团队动作，最该先看的不是“大家有没有学会更多 Git 技巧”，而是这几项：

  • CI 是否每次都在做不必要的全量拉取；
  • 大仓库是否需要 sparse-checkout 或 sparse-index；
  • 是否适合用 partial clone 降低传输和本地对象压力；
  • commit-graph、Bloom filters、MIDX、bitmaps 这类维护机制有没有被认真管理；
  • refs 规模、二进制文件、历史包袱是否已经影响日常操作；
  • 慢到底发生在本地磁盘、网络传输、对象存储，还是历史遍历。

这里有个限制也要说清：这些技术不是免费午餐。

sparse-checkout 会改变开发者看到的工作区。partial clone 会把一部分成本转移到后续按需取对象。维护策略需要有人负责，也需要团队接受约束。

问题不在于有没有银弹。问题在于很多团队连账本都没有。

从会开火车，到会调度路网

这件事让我想到铁路早期的变化：一开始，关键能力是会开火车；规模上来后，真正的能力变成调度路网。

类比不完全一样，但结构相似。

Git 在个人电脑上看起来很轻。一个命令，一个分支，一个提交。但在大型工程组织里，它背后是存储、索引、传输、权限、缓存、CI 和开发者体验。

工具表面越顺手，组织越容易偷懒。

仓库历史没人清，二进制文件乱进，refs 一路膨胀，CI 默认全量拉取。出事以后，再找一个“懂 Git 的人”救火。

这不是工程成熟。是把成本推迟。

“天下熙熙，皆为利来。”放到工程团队里，也说得通。每个人都会选择当下最省事的路径，除非组织把长期成本摊到流程里。

《High Performance Git》的价值就在这里。它没有把 Git 慢写成玄学，也没有把问题甩给某个开发者不会用。它把底层机制拆开，让团队知道该往哪一层查。

接下来最该观察的，不是这本书会不会变成大众爆款。它本来就不是写给所有人的。

更该看的是，大仓库团队会不会把 Git 性能纳入日常治理：CI 拉取策略、仓库维护计划、对象和 refs 管理、开发者本地体验监控。

如果这些还停留在救火阶段，Git 再熟，也只是个人熟练。组织并没有真正会用。