GitHub's agent-scale Git rebuild: separate branches should not share one write queue

GitHub’s agent-scale storage work targets a distinction that branching alone cannot enforce: independent branches should not have to share one repository-wide write queue. Its October 21 engineering article describes moving coordination toward individual references, while separating durable storage from read-serving compute. The reported improvements are internal tests and staged architecture work, not a promise that every customer’s pushes are already several times faster.

The practical consequence is specific. More branches can separate work logically; the storage system still decides whether unrelated writes wait for one another. And when those branches eventually converge on main, they are no longer independent updates to different references.

A branch is a separate name, not a separate storage queue

A branch looks like an isolated line of work in a development workflow, but that does not make it a separate repository on the server. Pro Git’s Git References chapter describes branches as names pointing to commit IDs, with local branch names under refs/heads/. Moving a branch updates a reference; it does not copy the whole history into a new storage system.

Consider a hypothetical pair of agents. One pushes to agent-a, another to agent-b. Those names point at different tips, and the two updates need not logically depend on each other. A backend can still impose one repository-wide critical section around both writes. Application-level separation has not removed the physical serialization point.

GitHub’s Building Git infrastructure for agent-scale development describes the existing Spokes arrangement: complete repository copies on local disks, five by default, with a quorum-based protocol for reference updates, requiring agreement from a majority of copies. Copies provide durable redundancy and spread reads. They also couple the work required to publish each write.

Now let both hypothetical agents finish and send their work through a merge queue targeting main. Those final updates contend on the same reference. It would be wrong to carry the independence of agent-a and agent-b through to that step. The architecture can stop unrelated branch writes blocking one another without pretending that competing changes to one branch tip no longer require order.

That is the problem worth following in this series, rather than the broader claim that agents require a new source-control product. GitHub is evolving its existing Git infrastructure, not asking the reader to replace a CLI or abandon the review workflow.

Per-reference coordination removes waiting, not round trips

The October 21 bridge-to-agent-scale article explains why moving copies across regions exposed the write ceiling. Spokes needs a majority to commit, but the described implementation waits for every healthy replica, up to a timeout, before moving on. A repository-wide lock remains held through that work.

On the migration path in the article, the target Azure region is roughly 1,000 miles away, with a round trip of about 25 milliseconds. A write needs multiple round trips. The relevant number is not simply the time to send one packet; it is how long the shared write path stays occupied while the distributed update completes.

For a repository already close to its sustainable write rate, adding that occupancy to every serialized write can make the queue grow. Opening more agent branches does not help if they all still enter the same queue. This is the point of narrowing serialization to references.

Under the per-reference model, writes touching different references can be in flight together. Writes that share a reference still wait for one another. Each write continues to experience cross-region latency; the change allows independent work to overlap instead of making all writers wait for one writer’s network rounds.

GitHub reports 3–4 times higher throughput with lower latency for writes to different references in internal tests using realistic traffic. The qualification is part of the result. It is not a benchmark for a single busy main branch, an entitlement for every repository, or evidence that every individual push lost its network delay.

The useful engineering lesson is about the scope of agreement. A repository is a convenient unit to name and operate, but it can be an unnecessarily large unit for serializing updates that touch different references.

More read replicas can make a coupled write path heavier

Reads create a different scaling problem. GitHub says most repositories see between 100 and 1,000 reads per write. CI and other automation can repeatedly fetch the same branch tip even when relatively little new data has been committed.

In the existing design, the machines holding durable repository copies also serve those reads. Adding another such replica increases read capacity, but that replica participates in writes too. The first article explicitly describes the resulting trade-off: more replicas can make writes slower. Read scaling is therefore not independent of the write ceiling.

The bridge design introduces a virtual write replica backed by Azure Blob Storage. The compute node streams incoming writes to object storage and serves no reads. In the described arrangement, a write is not acknowledged until the data is durable in object storage.

This is not a claim that durability becomes free. The article says the step adds some write latency. It also describes coalescing transactions on disjoint references into shared network I/O, allowing multiple independent updates to amortize a storage round trip. Per-reference concurrency and object persistence address different parts of the path; neither should be used as shorthand for eliminating consensus altogether.

Once that durable backing exists, read-serving workers can populate caches from it without joining the write quorum. More readers no longer have to mean more full participants in every write. The machines used for reads can also be configured for their own workload instead of sharing the same resource budget with compaction.

For an agent-heavy repository, that distinction separates two symptoms that can look identical in a dashboard. Slow fetches after a burst of CI fan-out and slow acceptance of pushes may share a storage system, but they do not necessarily need the same capacity change.

A read cache still needs the right reference state

Separating readers from the write quorum does not waive consistency requirements. A reader needs more than some available Git objects; it also needs the appropriate reference state for the operation it is serving.

GitHub describes virtual read replicas initially reconciling their local state against object storage in the background. That works for some reads, not every read. Supporting all kinds requires reconciliation in line with the request, fetching the reference state and data changed since the replica last caught up.

This is a useful limit on the phrase “stateless compute.” A replaceable worker can avoid owning the only durable copy while still needing to establish what it is allowed to return. Serving from a cache and returning an acceptably current branch tip are related tasks, not synonyms.

The article says its load-testing harness reached its own limits before the virtual read replicas did. The test therefore establishes a lower bound, not the system’s maximum capacity.

It also leaves work for later stages. The source explicitly says the quorum remains a bound on further write scaling. Immutable Git objects can be stored without agreement over their contents, but reference state still has to be ordered somewhere. The bridge is a staged reduction in coupling, not a declaration that the final coordination problem has vanished.

Read the migration denominator before the speedup

The most striking migration number in the October 21 article is 99.99999%. Its denominator is repositories with at least one copy in Azure—not all copies migrated, all traffic moved, or every new architectural stage deployed.

At that article’s snapshot, most repositories had two of five replicas in Azure, and Azure served about half of Git traffic. The first copy had arrived in the Central US region in August 2025. Those facts describe substantial progress, but they are different measures of progress.

The tiny remaining share included some of the busiest repositories. Counting repositories therefore cannot tell you how much of the hardest workload has moved. That is exactly why a very high copy-migration percentage can coexist with an important unresolved write-throughput problem.

The same care applies to the speedup figures. The earlier series article—first published October 6 and revised October 26—reports up to 35 times higher write throughput in internal benchmarks of the broader architecture. The bridge article’s 3–4 times figure concerns its per-reference step and a particular kind of traffic. They are not two measurements to multiply, nor two independent confirmations of one customer-visible result.

For a team running agents today, the immediate action is diagnostic rather than configurational. Separate the time spent accepting a push from waiting to merge into a hot reference, and separate both from repeated reads and repository maintenance. Those measurements identify the layer at which a change could help; they do not give access to GitHub’s internal quorum controls.

Nothing in the storage design is a reason to remove branch protections, bypass review or turn off required checks. The earlier article explicitly says the new infrastructure must preserve those controls. Making independent writes overlap is useful because it removes unnecessary waiting—not because it makes the necessary agreement over shared code disappear.