GitHub’s New Git Storage Design Separates Objects From Refs

A Git push has two very different kinds of work inside it. New objects add immutable history; a branch reference moves to point at the new commit. A storage system that treats both writes the same can spend unnecessary effort coordinating data that does not change with metadata that does. GitHub’s latest architecture separates those jobs as it prepares for unusually high push concurrency.

Objects and references have different jobs

Git stores commits, trees and blobs as objects identified by their content hashes. Once written, an object is not edited in place; a change creates a new object. References such as refs/heads/main, by contrast, are names that point to commits and can move when a branch advances. The distinction is foundational to Git’s object model. ^{[2] [3]}

That difference matters at service scale. A push may upload a pack of new objects and then update one or more references. Durable object storage can accept and retain large immutable data, while reference updates need coordination to prevent two concurrent writers from silently overwriting one another. The consistency problem is not eliminated by separating the layers; it becomes explicit and can be managed at the reference boundary.

GitHub’s engineering post describes its new design as a Git-compatible backend with durable packs in Azure Blob Storage, reference and manifest coordination through Ref-CAS, virtual replicas for read and write paths, and compaction nodes to reorganize stored data. The components are designed around different access patterns rather than requiring every reader or writer to participate in one shared mutable store. ^[1]

Why concurrency changes the design pressure

GitHub ties this work to a large increase in automated development activity. It reports that internal testing handled 5,000 concurrent agents and 7,200 pushes per second. Those numbers are useful as a signal of the workload the company is designing for, but they are vendor-reported test results. The article does not publish an independent benchmark, workload distribution, latency percentiles, or a direct comparison against the previous architecture. ^[1]

The more general lesson is that a source-control host has to preserve familiar semantics under a changing workload. If thousands of automated tasks create branches, push commits and update references at once, bulk object throughput is only part of the challenge. The system must also resolve races on branch names, make newly written history visible to readers, and recover cleanly from partial failures.

Separating immutable storage from reference coordination can make those responsibilities easier to scale independently. It also creates operational questions: how manifests stay synchronized with packed objects, how compaction affects read latency, how replicas handle stale state, and what consistency guarantees users observe after a push. GitHub’s post outlines its architecture but does not provide every implementation detail needed to evaluate those tradeoffs independently.

What developers should take from the preview

GitHub says the backend remains Git-compatible and identifies the current availability as a private preview, with a broader rollout planned for early 2027. That means developers should not expect a new command or need to redesign repositories based on the announcement. The near-term signal is about hosting capacity and the infrastructure required to make large numbers of agent-created changes reviewable and durable. ^[1]

Teams building agents on Git should still design for ordinary concurrency failures. Pushes can race, a branch can advance after an agent started, and a generated patch can conflict with human work. Make updates conditional on the expected base, use isolated branches or worktrees, retry only operations that are safe to retry, and expose the resulting commit and diff for review. A backend optimized for throughput does not decide which change should win.

For a related view of agent infrastructure, see our coverage of OpenAI’s planned Pierre acquisition. That announcement concerns code navigation, diffs and storage products, while GitHub’s post describes an internal platform architecture. Both point to infrastructure becoming part of the coding-agent product surface.

The design is about preserving familiar Git while changing the backend

The important claim is not that Git itself needs to be replaced. It is that the workloads surrounding Git are changing, so hosting platforms may need to store immutable history and coordinate mutable names differently. GitHub’s approach makes that separation central and reports ambitious load tests, but the broader rollout and production evidence will matter more than a private-preview number. Until then, the useful engineering idea is a familiar one: isolate data according to how it changes, then make the consistency boundary explicit.