共 4 篇
GitLab.com 早年打开一个仓库的 P99 超过 30 秒，CPU 却只用了 15 毫秒。顺着这个现象往下追：仓库为什么离开 NFS，一次 clone 由谁鉴权、pack 字节走哪条路，Gitaly 怎么把 RPC 变成受控的 git 进程、怎么扛住 CI 的并发 clone，push 怎么在 Gitaly 和 Rails 之间往返，Praefect 怎么投票、怎么修复落后的副本，最后看 WAL 和 MVCC 后端在当前源码里真正走到了哪一步。
Gerrit 的评审记录可以用 git fetch 拉下来，一次投票就是一个提交。顺着这个现象往下追：Gerrit 为什么用 JGit 自己做 Git 服务端，push 到 refs/for/main 时发生了什么，评审数据为什么从 SQL 搬进 Git，引用多到几十万个之后怎么存、怎么按权限过滤，合并时怎么保证原子性，索引和缓存怎么配合，以及多台机器之间怎么同步。
walgit 的一次 push 只对桶发 5 个请求，一次读只发 1 个，却保证 push 被确认后任何一台机器都能读到。顺着这两个数字往下追：为什么不能让 git 直接读对象存储，manifest 的 CAS 为什么就是提交点，并发 push 和“每个对象每秒一次写”怎么处理，读路径为什么要分级，日志怎么折叠和压缩，进程崩溃之后怎么办，以及 GitLab 的对象存储后端为什么选了另一条路。
一次 git clone 在网络上到底交换了什么？从抓包看到的三次 HTTP 请求出发，先搭一个最小的 Git 服务器，再顺着它解决不了的问题，依次读 GitLab、Gerrit 和 walgit 的源码：存储怎么拆、引用怎么管、多副本怎么保持一致。