Writing

GitHub's per-reference locking prepares Git for agent traffic

I think of Git as a version control system for humans. Commits, branches, pull requests—these are the units we work with. That framing hides an assumption: the number of concurrent writers to a repository stays low. A developer works on a few branches, pushes occasionally, opens a pull request. The repository's write coordination was designed around that pattern, and for most of Git's history that assumption held.

AI agents change the traffic pattern completely. They can open dozens of branches and push changes concurrently, far more than a single developer would. A coding agent might explore several approaches in parallel, update a branch for each experiment, and push all of them at once. When that becomes common, the old assumptions start to break, because the coordination points are no longer occasional human actions but a continuous stream of automated writes.

GitHub is rebuilding Git infrastructure to handle that shift. The core change is about write coordination. Previously, coordination happened at the repository level. If two operations touched the same repository, one waited. That was fine when a few pushes per hour were normal. But with agents, a single repository can see dozens of simultaneous branch updates. A repository-level lock means those updates get serialized, and agents spend more time waiting than working. The lock itself was not broken; it just assumed a low-write world.

The new model moves coordination to individual references: branches or tags. In Git, a reference is a pointer to a commit. Branches and tags are the main reference types. In plain English: instead of locking the whole project when one bot pushes, GitHub locks just that branch, so other branches keep moving. Two agents can push to different branches of the same repository at the same time without contending. Only writes to the same reference need to wait. This aligns the lock granularity with Git's own data model.

Why that matters: AI-assisted development is not just more code. It is more simultaneous writes to the same project. If the platform serializes those writes, the bottleneck is not compute or memory; it is the coordination model underneath. GitHub's internal tests show 3-4x higher throughput with per-reference coordination. That is a significant difference when you are running hundreds of agents against the same repository. It means agents spend time working instead of waiting for a lock.

There is a counterexample worth keeping in mind. For normal human workflows—a few pushes per hour—the old repository-level lock was fine. The overhead was invisible. It only becomes a bottleneck when agents behave like a swarm. That distinction is important because most Git users will never notice the change. It is an infrastructure change aimed at a specific usage pattern, not a general speedup for everyone. In fact, for a solo developer, the new per-reference coordination might not change anything observable.

Scaling for AI isn't always about GPUs—it's about the coordination model underneath.

This is a good reminder that scaling for AI is not always about GPUs. Sometimes it is about the coordination model underneath. If you only optimize the compute layer and leave a repository-level lock in place, you will hit a wall long before you run out of GPUs. The quiet work of changing how a platform coordinates writes can matter more than adding more hardware. It is also a reminder that infrastructure assumptions are usually invisible until a new workload breaks them.

Originally covered at github.blog ↗