北京
在超大型软件公司里，把所有代码塞进一个不断膨胀的“单体仓库”（monorepo）早已是常规操作，但这套玩法带来的麻烦却一点都不常规。Uber的工程团队就长期被这种巨型仓库折腾：光是克隆一次Go语言的主仓库，就要硬等15分钟，还吃掉了海量计算资源，对于同时需要拉取多个仓库的服务，存储和处理的压力会成倍叠加。
但这并不是最让人头疼的地方。真正的瓶颈出在上游的Git服务器——每天承受着数百万次克隆和抓取请求，每来一个请求都得老老实实枚举对象、把数据流式吐回去，结果就是全公司的开发效率和系统稳定性一起被拖下水。无论是Jenkins还是Buildkite这类CI平台自带的缓存机制，都只能算是“头痛医头”。这些方案光是为了跑一条简单的Git命令，也要先把完整的构建环境预备好，笨重又低效；再加上缺少一个独立的Git操作接口，各个构建代理只能各拉各的，状态越积越旧，Git操作被死死绑在构建生命周期上，连预热和程序化调用都成了奢望。
Uber决定不再打补丁，自己动手造了一个专门解决这类问题的内部平台，取名GitFarm。它不是另一个源码管理工具，而是一个运行在云上的、极致优化过的Git客户端，替其他服务跑标准的Git命令。这种“Git即服务”的思路只有一个目标：把以往压在本地检出和操作上的高昂开销全部砍掉。
GitFarm的杀手锏是500毫秒内就能交出一个完整的Git工作目录。这一速度靠的是两点：安全的临时沙盒和预先加热好的状态。所有Git命令都在隔离的沙盒里执行，而这些沙盒早已被“预热”过，跳过了传统流程里最耗时的对象枚举和传输环节，让开发者根本感觉不到背后那个多GB仓库的存在。
换个角度看，相当于Uber把“等15分钟”这种事从开发链条里彻底剔除了。虽然GitFarm的更多实现细节目前还没有完整披露，但它的出现已经重新定义了大规模单体仓库的日常体验——不再需要为了代码库的规模向效率妥协，也意味着数百个自动化系统能在同一套代码底盘上跑得更快、更稳。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
