北京
作者 ｜ Leela Kumili
译者 ｜ 明知山
Uber 推出 Git 即服务平台 GitFarm，用于在其大规模单体代码库上执行 Git 操作。通过将代码库操作迁移到共享服务，GitFarm 不再要求客户端系统进行本地代码克隆，使客户端资源占用降低了 80% 以上。
Uber 的自动化系统每天会在支持 Go 语言、Java、Python、Web、Android 和 iOS 的单体代码库上调用数百万次 Git。此前，各个服务都维护着完整的代码库检出副本，包括读取文件、验证变更和计算合并基础等操作。克隆 Uber 的 Go 语言单体代码库大约需要 15 分钟，需要约 6 个 CPU 核心、32 GB 内存和超过 40 GB 的磁盘空间。
Uber 工程团队在介绍 GitFarm 的 LinkedIn 帖子 中表示，该服务可在 500 毫秒内完成完整的 Git 检出，并消除了以往 10 到 15 分钟的主机级冷启动时间。
本地克隆与反复的代码库同步操作使得传统 Git 工作流成为了严重的基础设施瓶颈。
GitFarm 架构（来源：Uber 博客文章）
GitFarm 通过高性能的 gRPC API 暴露 Git 操作。它不是一个源代码管理系统，而是充当一个中心化的 Git 客户端，代表其他服务执行标准的 Git 命令。网关对请求进行认证和授权，然后将其路由到后端集群，命令在隔离的、临时的沙箱中运行。
后端维护裸代码库克隆，并使用推送式更新和定期抓取与上游代码库保持同步。它还维护代码库检出和沙箱容器池。当请求到达时，GitFarm 可以将一个预热的检出挂载到一个可用的沙箱中，而不是从头开始创建代码库克隆和执行环境。Uber 表示，这种池化机制将提供就绪检出的开销缩短到一秒以内。
GitFarm 通过双向 gRPC 流会话支持多命令工作流。命令可以在同一个检出上顺序执行，允许诸如获取分支、计算合并基础和推送派生引用等工作流，无需重复初始化代码库状态。客户端也可以在需要最新上游状态时显式执行 git fetch，而能够接受有限数据滞后的工作负载可以使用后端同步的代码库状态。
GitFarm 后端架构 （来源：Uber 博客文章）
Uber 透露，某代码所有权服务在采用 GitFarm 后移除了跨六台主机的本地检出，将 CPU 消耗从 70 多个核心降低到 16 个，内存从 400 GB 降低到 32 GB。启动时间从 15 到 20 分钟缩短到不到一分钟。某合规审计服务每小时处理 10000 到 20000 个事件，跨越 9000 个代码库，通过消除调度、工作空间初始化和代码库同步开销，将中位延迟从使用 Buildkite 时的 110 到 160 秒降低到使用 GitFarm 时的 20 到 30 秒。
该架构也支持编码智能体工作负载。Ashish Verma 在 LinkedIn 上指出，智能体会反复搜索、分支、差异比较、实验、重试和验证变更，并且是并发进行的，这可能会增加 Git 基础设施的工作负载。
自 2025 年初投入生产环境适应以来，GitFarm 的功能路线图包括流式 Git 输出、稀疏检出、裸工作空间、更长时间的会话、代码库镜像 和 SubmitQueue 集成。
查看英文原文：
https://www.infoq.com/news/2026/08/uber-gitfarm-git-as-a-service/
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
