北京
周三下午三点，一位基础设施工程师盯着终端上“git clone”的进度条，已经跑了12分钟。这不是偶然——他所在的团队有约200万次提交，仓库体积臃肿到28GB，任何新同事入职第一天都在等待中消耗热情。他打开记事本，决定不再忍受这种“可衡量的浪费”。
慢的不是Git本身，是三个环节同时塌方：仓库怎么打包、客户端要了什么、服务器怎么交付数据。他发现症状很集中——构建节点的磁盘占用高得离谱，大量克隆时源服务器CPU出现尖峰，甚至git gc都无法正常完成。这些迹象指向一小撮根源：过多的小包或配置糟糕的包、传输了不必要的对象、服务器端缺少可达性位图与提交图，以及未优化的大文件处理。每一项都是可以修正的。
动手之前，他先做了测量。全链路的耗时被拆成网络传输、服务器生成包文件的CPU时间、以及客户端解包的CPU与磁盘时间。基线测量直接用“time git clone --progress <仓库地址>”记下墙钟时间；然后开启Git的性能追踪，用GIT_TRACE_PERFORMANCE等四个环境变量捕获协商和包访问的痕迹，寻找热点。他还跑了git-sizer --verbose来摸清仓库的痛点：blob的数量与体积、最大的树对象、引用压力，这些指标和慢克隆高度相关。在裸仓库上执行“git -C /path count-objects -vH”时，他看到大量松散对象和无数小包文件——这是明确的危险信号。服务器端则监控git-upload-pack的CPU和内存占用，记录包创建与传输的时间占比。最终他形成了一套KPI：平均克隆时间、取回时间中位数、包文件数量、最大包尺寸、超过某个体积阈值的blob数量，以及使用了--filter或LFS的克隆比例。
测量结果告诉他瓶颈到底卡在哪条链路上——是带宽、服务器CPU还是客户端解包——从而决定在重新打包时用CPU和内存去换更小的传输体积和更少的解包开销。有了数字，他开始压缩字节。
如果仓库是个仓库，最占地方的是历史堆里的大文件和到处散落的小包装盒。他第一刀切向包文件调优，强制生成可达性位图和提交图，把大量小包合并成少量索引良好的大包。接着清理仓库：用git gc --aggressive和BFG Repo-Cleaner去掉被错误提交的虚拟机镜像和日志文件，再配合git filter-repo重写历史。随后他在客户端只给开发者需要的部分：浅克隆（--depth）砍掉历史深度，稀疏检出（--sparse）只拉取仓库子树，部分克隆（--filter=blob:none）完全跳过blob直到真正用到它们时才按需获取。这三种策略组合起来，让克隆从下载全部对象变成只传输当前树引用和目录结构，数据量骤降。
服务器端也不能闲着。他配置了预先生成包文件并在多区域做缓存，利用CDN分发静态对象，同时优化git-upload-pack的HTTP后台参数以避免重复计算。对于必须留在仓库里的大文件，转向Git LFS，把指针文件留在仓库，实际大文件另存到低成本存储并开启加速。整套方案落地以后，那个原本要42分钟的全量克隆变成90秒的浅克隆，CI管道的排队现象消失了，版本服务器CPU使用率平滑得像一条直线。他没有发明任何新算法，只是对着测量数字，一项项去调整包的形状、请求的范围和服务器的交付方式。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
