GitHub 为 AI Agent 时代重建 Git 存储层

GitHub recently published a blog post explaining that it is rebuilding the system that stores all of its Git repositories, and the reason is AI agents. Not models, not features: the storage layer underneath every repository on the platform. Here is what is breaking, and how GitHub plans to fix it. GitHub rebuilds Git storage for AI agents · NotVibesCoded AI agents commit and push after almost every step, and that traffic broke the scaling assumptions underneath GitHub. The company is rebuilding its Git storage… notvibescoded.com The Scale of the Problem In September, developers and agents made 7.38 billion commits on GitHub, more than five times as many as a year earlier. Pushes grew by almost the same factor, reaching 3.35 billion a month. Merged pull requests are at nearly four times last year's volume, and GitHub Actions logged 3.26 billion runs in September alone. These are not numbers a system designed around human working rhythms absorbs by accident. They are what happens when the "developer" on the other end of a push is a loop. What a Push Actually Does Git stores two kinds of things: Objects are every file, folder, and commit. Each is named by a hash of its content, and once written, an object never changes. Refs are names that point to a commit. A branch like main is just a ref, and it changes all the time. A push therefore does two things: it uploads the new objects, then moves the ref (for example, main) to the new commit. What Agents Change A person might push a few times a day. An agent working in a loop can push after almost every step, so the time one push takes becomes the agent's speed limit. As GitHub's Brian Celenza puts it, an agent commits or checkpoints after nearly every action, and waits for each push to finish before continuing. In the largest repositories, GitHub says thousands of agents can be working at once, each on its own branch. All of those writes land in the same place in GitHub's system. When the work is merged, it goes through a merge queue into main, so every merge competes to move the same ref. Each push also triggers thousands of reads. CI and code scanning fetch the same commit thousands of times a minute. Reads like these are easy to scale with copies and caches. Writes are the hard part, because every push has to be saved safely and seen the same way by everyone. How GitHub Stores Repositories Today The current system is called Spokes. It keeps a full copy of every repository on five file servers, and reads are spread across those copies. When a push moves a ref, a coordinator asks the copies to agree, and a majority (three out of five) must say yes. The trouble is that these copies do two jobs: they keep the data safe, and they serve the reads. When a busy repository needs more read capacity, GitHub adds another full copy. But every copy takes part in every write, and a write waits for the slowest copy. More copies therefore means slower writes, which creates a ceiling for the busiest repositories. In Celenza's words: "Every replica participates in every write, so a push is only as fast as the slowest replica in its set." GitHub's answer is to separate the two jobs, keeping data safe and serving traffic, using two main ideas. Idea One: Coordinate Only What Needs Agreement Today, a push saves the objects, checks them, and scans for leaked secrets in a single coordinated step, and only then moves the ref. But only the ref update actually needs the copies to agree. As things stand, a second push has to wait for the whole of the first. In the new design, the heavy steps run in parallel, so pushes only queue for that one small step. This matters most for main, where every merge waits for the one before it. If moving the ref takes 300 milliseconds, main can handle about three merges a second. At 10 milliseconds, it can handle about 100. Making that single step faster speeds up every merge. Idea Two: Separate Storage From Compute The second idea is to split storage, where the data lives, from compute, the machines that answer requests. The authoritative copy of each repository moves to Azure Blob Storage, which keeps it safe and replicated and becomes the single source of truth. Reads are served by lightweight workers layered on top, each keeping a cache of the data it serves. When CI fetches the same commit thousands of times, the workers answer and the push does no extra work. If a worker fails, nothing is lost. It is simply a cache miss, and a new worker fills its cache from storage. The Results In GitHub's internal benchmarks, the new design handles up to 35 times more write throughput. GitHub says the next post in the series will go deeper into the new architecture, and it will be worth covering once it is out. The Takeaway Two principles stand out: keep the part that needs agreement as small as possible, and don't make the copies that keep your data safe do the serving as well. What It Means for the Rest of Us You are not running GitHub's storage layer, but if you run agents against your own repositories, the same physics apply at your scale. Commit frequency is a load decision: an agent that pushes after every step multiplies CI runs, review notifications, and merge contention exactly the way it multiplied GitHub's. Batching agent work into fewer, larger pushes, gating merges instead of every checkpoint, and keeping the coordination points in your own workflow (approvals, required checks, the merge itself) as small and fast as possible are the same two principles, applied to a team instead of a platform. The infrastructure of software development was designed around humans who commit when they've finished thinking. Agents commit while they think. Everything downstream, storage, CI, review, is being rebuilt for that difference, starting, apparently, with GitHub itself. Source: GitHub Engineering, Building Git infrastructure for agent-scale development, October 6, 2026. This piece is published on NotVibesCoded, alongside field guides on context files for coding agents, reviewing AI-generated PRs, and shipping AI-built software without the slop.