GitHub Rebuilds Its Git Backend for Agent Fleets After 7.38 Billion Commits in September

GitHub is rebuilding the Git infrastructure behind its platform to cope with software written by agents as well as people. In an engineering post published on October 6, 2026, the company said developers and agents made 7.38 billion commits on GitHub in September alone, more than five times as many as a year earlier. The post describes the new architecture’s design principles rather than a finished product. GitHub says the work is happening “while GitHub keeps running,” with no maintenance window and without asking developers to change how they build software. A follow-up post will go deeper.

The numbers behind the rebuild

The post sets out the growth that prompted the work. Between September 2025 and August 2026, total Git activity on GitHub more than doubled, from 218.2 billion to 473.3 billion events a month. Pushes rose 4.9 times year over year, from 0.69 billion to 3.35 billion a month. Pull request merges reached nearly four times their volume of a year earlier. GitHub Actions ran 3.26 billion times in September, more than four times the figure from a year before. The activity is also very uneven: the busiest repository on GitHub handled roughly a billion requests in August.

GitHub ties much of the growth to repositories where “large engineering teams running busy CI pipelines” now also run “growing fleets of agents.”

Why agents stress writes, not reads

The post argues that agents change the shape of load, not just its size. An agent in a tight loop commits or checkpoints after nearly every action, so the time a single push takes to complete becomes its speed limit. Thousands of agents on their own branches in one repository produce a sustained write rate that converges on one point in the architecture. Trunk-based development and merge queues then funnel that work onto a single reference. Each push can also fan out into thousands of reads, because CI and code scanning clone or fetch the same branch tip thousands of times per minute.

GitHub says reads are the easier half. Caches and replicas can serve the same bytes to more clients. Every write, though, has to be stored durably and made visible consistently before the next agent or CI job can build on it.

Where Spokes hits a ceiling

GitHub’s storage system, Spokes, keeps a full copy of each repository on the local disks of several fileservers, five by default. When a push updates a reference, a three-phase commit protocol uses a quorum so that CI, the web UI, and API clients see a consistent state. The company says this design serves a billion repositories today.

The problem is that the same mechanism handles both durability and scale. The on-disk copies are the source of truth, so adding read capacity means adding another durable replica, and every replica takes part in every write. A push is only as fast as the slowest replica in its set. Adding replicas to absorb reads therefore makes writes slower, losing a replica cuts read capacity, and losing quorum stops writes entirely. For most repositories that trade-off is fine. For the busiest, GitHub calls it a ceiling.

Splitting durability from compute

The new design rests on two ideas. The first is to coordinate only what needs agreement. In a push, that is the reference update itself. Storing objects, validating object connectivity, and secret scanning can run in parallel with other writes, which shortens the critical path to the acknowledgment. Compaction and garbage collection, which currently run on the same hosts that serve live Git requests, move to separate workers that operate directly against durable storage.

The second is to decouple storage from compute. Authoritative repository data will live in Azure Blob Storage. Read capacity will come from lightweight workers that cache data, so CI fan-out and agent fleets can be absorbed without adding work to every push. Losing a compute worker becomes “closer to a cache miss” than a rebuild. Capacity can also scale up for a burst, such as a release or a new agent fleet coming online, and shrink once it passes.

GitHub says the architecture has delivered up to 35 times higher write throughput in internal benchmarks, with read capacity that scales independently. It has not given a timeline for when repositories will move to the new design.

Controls that have to survive

The post states that branch protections, required reviews, audit logs, and repository visibility controls must carry over unchanged. Its stated principles are to build on workflows developers already trust, to put reliability first, and to keep people in control of their code, so that “as agents take on more of the work, the people who own the code can still review, understand, and approve it.”