Uber Develops GitFarm for Git Operations as a Service in Large Monorepos

Addressing Monorepo Challenges

Uber has created GitFarm, a Git as a Service platform, to handle Git operations within its extensive monorepos. The company's automation systems execute Git commands millions of times daily across monorepos supporting various programming languages and platforms, including Go, Java, Python, Web, Android, and iOS. Previously, individual services maintained full repository checkouts, leading to significant resource consumption and time delays.

Performance Improvements

By centralizing repository operations, GitFarm eliminates the need for local clones on client systems, resulting in an 80% reduction in client-side resource utilization. Uber reports that GitFarm provides full Git checkouts in under 500 milliseconds, removing previous cold start times of 10 to 15 minutes. This improvement addresses the infrastructure bottleneck caused by local cloning and repetitive repository syncing in traditional Git workflows.

Architectural Overview

GitFarm exposes Git operations through a high-performance gRPC API. It functions as a centralized Git client, executing standard Git commands on behalf of other services rather than acting as a source control management system. A Gateway authenticates and authorizes requests, routing them to backend clusters where commands run in isolated, ephemeral sandboxes.

Optimized Checkout Process

The backend maintains bare repository clones, kept synchronized with upstream repositories via push-based updates and periodic fetches. It also manages pools of repository checkouts and sandbox containers. When a request arrives, GitFarm can mount a pre-warmed checkout into an available sandbox, bypassing the need to create a repository clone and execution environment from scratch. This pooling mechanism reduces the overhead of providing a ready-to-use checkout to less than a second.

Support for Complex Workflows

GitFarm supports multi-command workflows through bidirectional gRPC streaming sessions. This allows commands to execute sequentially against the same checkout, enabling workflows such as fetching a branch, calculating a merge base, and pushing a derived reference without repeatedly initializing repository state. Clients can explicitly run `git fetch` for the latest upstream state, while workloads tolerating bounded staleness can use the backend’s synchronized repository state.