The bridge to agent-scale Git infrastructure

GitHub just shared how they migrated 99.99999% of their repositories to Azure while solving one of distributed systems’ toughest problems: keeping Git data consistent at planetary scale. If you’re building cloud infrastructure or working with CI/CD pipelines, this matters to you because it reveals how to handle Git as a first-class distributed service rather than a simple file store.

Here’s what GitHub tackled: Git’s traditional architecture assumes a single source of truth. But when you operate globally with millions of repositories, you need copies everywhere—yet those copies must stay synchronized and never diverge. Their solution uses per-reference quorums, a technique borrowed from distributed databases but applied to Git objects. Instead of requiring all replicas to agree on every single operation (which kills performance), they only require agreement on specific references that matter most. This means read operations can scale independently across regions without waiting for slow consensus. When an agent in Tokyo pushes code, it doesn’t need permission from a quorum in Virginia; only the reference update itself goes through consensus. The actual Git objects—the heavy data—stream through object storage that can scale horizontally.

Think about your own workflows: every CI/CD pipeline that clones repositories is a read operation. Every deployment agent, every build server, every developer in a different timezone. Traditional Git infrastructure makes all these operations contend for the same underlying storage and replication logic. GitHub’s approach separates these concerns. Object storage handles the immutable data (which never changes once written), while the reference layer handles the mutable pointers (branches, tags, HEAD). This is the same principle databases use when they separate blob storage from metadata—it’s just applied to Git. You can now scale read capacity by adding more object storage replicas without rearchitecting the consensus layer.

The practical impact: this infrastructure lets GitHub run AI agents, automated tools, and massive CI/CD fleets that pull repositories constantly without starving human developers trying to push code. If you’re managing self-hosted Git infrastructure, thinking about federation, or building automation that treats repositories as data sources (not just code stores), study this approach. The per-reference quorum pattern works because it recognizes that not all Git operations have equal importance—merges need strong consistency, but reads can be eventually consistent across replicas. That’s not just an optimization; it’s a fundamental rethinking of how to scale Git beyond single-node limitations.