布莱恩·塞伦扎
布赖恩是一位首席软件工程师，致力于为GitHub上所有存储器交互提供动力的存储和核心服务。
我们重建GitHub的基特基础设施，同时GitHub不断运行，为agent规模的软件开发打下基础。
|
|
9分钟
每天在GitHub上，数百万的开发者会建造他们所依赖的客户的产品，为开源做出贡献，并追求个人项目。 GitHub的架构在过去几年中发生了稳步变化，以支持该作品以及依赖该作品的开发者和组织日益增长的需求。
代理软件开发正在推动下一个建筑转变。 由于开发者和agents同时在存储器中工作，每天收到数百万的承付，这些工作量需要不同的Git架构。 我们正在重建GitHub的Git基础设施，这篇文章探讨了塑造这项工作的要求及其背后的设计原则。
今天工作量最多，典型的寄存器与最繁忙的寄存器之间的差距比大多数人预期的要大。 以下是从2026年8月起GitHub的月度寄存器活动分布的简图：
仓库活动在分布的远端急剧攀升。 8月，GitHub最繁忙的存放处收到了大约10亿个请求。
除了这些数量最高的工作量外，GitHub上的Git活动总量也在迅速增长：2025年9月至2026年8月，从每月2 182亿次增加到4 733亿次，增加到先前的2x以上。
仅在9月份，开发商和agents在GitHub上承诺了73.8亿美元，是一年前的5倍多。
本曲线顶端的储物库显示其前缘的代理开发是怎样的：大型工程团队在不断增长的agents舰队同时运行繁忙的CI管道。 支持这些团队意味着建立Git基础设施，我们正对Git的基础设施进行深入投资，以满足代理软件开发的需求，并为团队最雄心勃勃的工作量奠定基础。
为这一规模而建设意味着应对若干建筑挑战：
- 交接转弯会成为agent的瓶颈几乎每一次行动之后，agent在紧锣密鼓地实施或设置检查站。 它的速度被一个单一的推力完成的速度所限制，因此人类永远不会注意到的暂时性成为了限制因素。
- 书面吞吐量需求按数量级递增。 推力逐年增长4.9倍，从每月的6.9亿升至33.5亿。 成千上万的agents在一个寄存器中工作在自己的分支上产生一个持续的写速率，它聚集在我们建筑的单一点上。
- 合并有一次争吵基于 Trunk 的开发，释放列车，和合并队列漏出所有工作到一个需要吸收每次合并的单调。 在GitHub上拉请求合并一年前增加到近4x的体积
- 每一个都推成几千个读数例如，CI和代码扫描克隆或每分钟获取上千次相同的分支提示，而粉丝输出必须便宜。 GitHub Actions单在9月就跑出32.6亿次，比一年前的4倍多。
- 存放处的操作必须继续迅速。 为了保持速度，我们不断压缩存储器数据，清理不再需要的物体。 每个新书写新增的作品，成本化合物随着体积攀升。
这就是为什么快速克隆只解决部分问题的原因。 阅读比较容易进行规模化：添加缓存，添加复制品，为更多的客户端服务相同的字节。 扩大范围是必要的，但这些工作量需要的不止于此。 写作更难在下一个agent或CI任务能够在此基础上更上一层楼之前，每个推力必须持久地存储，并一致地显示。
目前的建筑多年来为开发者提供良好的服务。 每个寄存器都由Spokes存储，它将一个完整的副本保存在多个文件管理员的本地磁盘上，默认为5个。 这些快速本地磁盘让 Git 操作以低延迟读取本地寄存器数据，额外的副本在分散阅读到文件编辑器时提供了冗余。 当一推更新一个引用时，一个三阶段的承诺协议使用一个法定人数来确保CI,web UI,API客户端看到一个一致的寄存状态。 今天，这种配对服务了十亿个储存库。
然而，我们使用的耐久性机制与我们使用的规模机制相同。 磁盘上的复制品是真理的来源，所以添加读能力意味着添加另一个耐久的复制品。 每个复制品都参与每个写作，所以一个推力只有其剧集中最慢的复制品一样快。 网效：增加复制品吸收读载量使写作速度放慢。
对于大多数寄存器来说，这种权衡效果很好。 在最高的活动水平上，它变成了一个上限：增加阅读复制品新增的俯冲写法，失去复制品会降低阅读能力，失去法定人数会完全停止写法。 为了满足agent的第一要求，我们需要将耐久性与规模区分开来，而不失去今天的球队所依赖的。
我们重建基础设施，没有任何维护窗口可以让世界代码停止移动
我们为GitHub最苛刻的工作量而建设：一个在严格监管要求下的企业航运，一个团队在建设操作系统的Repo上着陆一个变化，一个组织运行着数千个agents对一个单一的代码库。 在融资这个比例尺的工程中为所有人准备的地板负责审查各时区志愿者贡献的维护者，以及学生开启他们的第一次拉力请求，获得同样更快，更具有复原力的基础。
新架构还必须保留已经运作的控制小组。 维护者需要分支保护并需要审查，因此未经审查的更改永远不会到达默认分支。 安全小组需要审计记录和数据库可见度，以调查可疑的访问事件。 待命工程师需要可靠的自动化和足够的可观察性，以了解部署失败的原因。
我们的指导原则是：
- 开发人员已经信任的工作流程。 团队依靠分支，审查，合并等工作流程以及历史来构建，运输，并大规模治理软件。 我们的新基础设施旨在以高得多的活动量支持同样的工作流程。
- 把可靠性放在首位。 我们以开发商和组织所需的可靠性来衡量每一项决定。 对平台的信心是让一个工程组织建立自动化，按期发船，履行遵守义务，并了解它生产的软件。 这项工作将有意义地提高吞吐量和规模，这些成果为已经存在的信任奠定了基础。
- 让人们控制他们的密码如果这个系统不能帮助使用它的人和组织，随着agents承担更多的工作，拥有代码的人仍然可以审查，理解，批准。
我们正在建设一个新的GitHub架构，能够更有效地扩大规模。 我们的方法围绕着核心分布式系统设计原则，适用于代理软件开发的货币和规模。 我们的目标是继续推动世界各地与Git和GitHub共同建设项目的开源社区和企业的前进势头，同时维护和调整周围的特征和控制，以满足代理时代的新需要。
一个接收许多推力的寄存器必须迅速接受并发布更新。 协调在保护正确性时是有价值的，但过多地限制了书写吞吐量，可以把繁忙的寄存器变成瓶颈。 我们目前的建筑在不需要的地方紧密结合，这限制了我们跨越阅读和写作的能力，我们正重新设计系统，以保持Git语义学需要的协调
- 只需要协商就可以了真正需要达成一致的推动部分是参考更新本身。 存储基础对象，验证对象连接，以及秘密扫描等工作要多得多，但大部分可以与其他写作平行进行。 这缩小了推动采取需要协调的小步骤的关键道路，因此其他工作不再拖延承认。
- 把维护移离服务路径。 收缩和垃圾收集是寄存器最繁忙的工作之一，今天它们运行在同样的主机上，回答现场的Git请求。 在新建筑中，分开的工人直接处理与耐久储存的维护。 繁忙的寄存器可以在背景中持续优化，而不会减慢推力和获取。
今天，本地磁盘上的完整寄存器副本既可用作耐用存储，也可用作回答Git请求的层。 把两者分开，让我们各自独立衡量。
- 缩放不添加耐用拷贝。 在新架构中，阅读能力来自缓存数据以服务请求的轻量级工人。 该寄存器的权威性副本位于下面一个持久的存储层。 这样，平台就可以吸收来自CI扇出，agent机队的大型读尖，以及大型克隆人，而无需在每次推力中添加工作。
- 让每一层都做一个工作。 权威寄存器数据生活在Azure Blob存储中，这已经提供了Azure规模的耐久性和复制性。 计算层在最低纬度时对吞吐量进行优化。
- 从失败中恢复更快当存储和计算结合时，丢失一个主机既会降低容量，也会降低耐久性，恢复意味着重建一个完整的寄存器副本。 当他们分开时，失去计算工人更接近缓存误差：替代工人可以马上开始服务请求，并随着交通的到来从持久存储处补充其缓存。
- 满足需求的能力。 计算工人可以随着交通变化而增减，而不是预先提供高峰负荷。 一个正在经历活动爆发的寄存器，比如发布或一个新的agent机队上线，可以获得额外的爆发能力。 一旦它过去，这种能力就会消失。
这些原则共同使我们能够支持更高的吞吐量和更多的同时工作，同时又不放弃用户所需的可靠性和控制。
我们正在建造一个能够提供最大吞吐量和可靠性的建筑。 独立读写规模，系统从失败中优雅地恢复。 在内部的基准测试中，它提供了高达35倍的书写吞吐量，其读取能力可以自行缩放以满足需求。
随着自动化开发增加软件变化的频率和货币化，GitHub将不断演变其基础，而不交易团队所依赖的治理和控制。 我们已经开始建立这个基础。 我们将会更深入地探索未来架构
我们是如何将github.com从CSS-in-JS完全迁移出去的。
我们如何在GitHub Copilot应用中重建diff表面，以打开一个有数百个内线评论的百万线牵引请求。
为什么更短的输出成本会更高，GitHub Copilot如何减少整个编码任务的浪费工作。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Brian Celenza
Brian is a Principal Software Engineer working on the storage and core services that power all repository interactions on GitHub.
We’re rebuilding GitHub’s Git infrastructure while GitHub keeps running, creating a foundation for agent-scale software development.
|
|
9 minutes
Every day on GitHub, millions of developers build the products their customers rely on, contribute to open source, and pursue personal projects. GitHub’s architecture has changed steadily over the years to support that work and the growing demands of the developers and organizations who depend on it.
Agentic software development is driving the next architectural shift. With developers and agents working concurrently in repositories that receive millions of commits a day, these workloads demand a different Git architecture. We’re rebuilding GitHub’s Git infrastructure to support them. This post explores the demands shaping that work and the design principles behind it.
Today’s highest-volume workloads show the scale we’re building for. The gap between a typical repository and the busiest ones is wider than most people expect. Here’s a rough picture of the monthly repository activity distribution on GitHub from August 2026:
Repository activity climbs sharply at the far end of the distribution. The busiest repository on GitHub saw roughly a billion requests in August.
Beyond these highest-volume workloads, total Git activity on GitHub is also growing rapidly: between September 2025 and August 2026, it increased to more than 2x its previous level, from 218.2 billion events per month to 473.3 billion.
In September alone, developers and agents made 7.38 billion commits on GitHub, more than five times as many as a year earlier.
The repositories at the top of this curve show what agentic development looks like at its leading edge: large engineering teams running busy CI pipelines alongside growing fleets of agents. Supporting these teams means building Git infrastructure for sustained, concurrent reads and writes at a scale few repositories reach today. We’re investing deeply in Git infrastructure to meet the demands of agentic software development and give teams a foundation built for their most ambitious workloads.
Building for this scale means addressing several architectural challenges:
- Commit turnaround becomes a bottleneck per agent. An agent in a tight loop commits or checkpoints after nearly every action. Its speed is bounded by how fast a single push completes, so latency that a human would never notice becomes the limiting factor.
- Write throughput demand is increasing by orders of magnitude. Pushes grew 4.9x year over year, from 0.69 billion to 3.35 billion per month. Thousands of agents working on their own branches in one repository produce a sustained write rate that converges on a single point in our architecture.
- Merges contend on one reference. Trunk-based development, release trains, and merge queues funnel all that work onto a single ref that has to absorb every merge. Pull request merges on GitHub grew to nearly 4x their volume a year ago.
- Each push multiplies into thousands of reads. For example, CI and code scanning clone or fetch the same branch tip thousands of times per minute, and that fan-out has to be cheap. GitHub Actions alone ran 3.26 billion times in September, more than 4x as many as a year ago.
- Operations on a repository must continue to be fast. To keep them fast, we continually compact repository data and clean up objects that are no longer needed. Every new write adds to that work, and the cost compounds as volume climbs.
This is why fast clones only solve part of the problem. Reads are relatively easy to scale: add caches, add replicas, and serve the same bytes to more clients. Scaling reads is essential, but these workloads require more than that. Writes are way harder. Every push has to be stored durably and made visible consistently before the next agent or CI job can build on it.
The current architecture has served developers well for years. Every repository is stored by Spokes, which keeps a full copy on the local disks of several fileservers, five by default. Those fast local disks let Git operations read native repository data with low latency, and the extra copies provide redundancy while spreading reads across fileservers. When a push updates a reference, a three-phase commit protocol uses a quorum to ensure that CI, the web UI, and API clients see a consistent repository state. That pairing serves a billion repositories today.
However, the mechanism we use for durability is the same one we use for scale. The copies on disk are the source of truth, so adding read capacity means adding another durable replica. Every replica participates in every write, so a push is only as fast as the slowest replica in its set. The net effect: adding replicas to absorb read load makes writes slower.
For most repositories, this tradeoff works well. At the highest activity levels, it becomes a ceiling: adding read replicas adds overhead to writes, losing a replica reduces read capacity, and losing quorum stops writes entirely. To meet agent-first demands, we need to separate durability from scale without losing what teams rely on today.
We’re rebuilding the infrastructure while GitHub keeps running. There’s no maintenance window where the world’s code stops moving, and no version of this work where we ask people to change how they build software while we do it.
We’re building for the most demanding workloads on GitHub: an enterprise shipping under strict regulatory requirements, a team landing a change across a repo that builds an operating system, and an organization running thousands of agents against a single codebase. Engineering for that scale raises the floor for everyone. The maintainer reviewing contributions from volunteers across time zones and the student opening their first pull request get the same faster, more resilient foundation.
The new architecture also must preserve the controls teams already operate on. A maintainer needs branch protections and required reviews so an unreviewed change never reaches the default branch. A security team needs audit logs and repository visibility to investigate a suspicious access event. An on-call engineer needs dependable automation and enough observability to understand why a deployment failed.
For the platform to keep serving everyone here while it scales for the busiest workloads, these are our guiding principles:
- Build on the workflows developers already trust. Teams rely on workflows like branching, review, merge, and history to build, ship, and govern software at scale. Our new infrastructure is designed to support those same workflows at much higher volumes of activity.
- Put reliability first. We measure every decision against the reliability that developers and organizations require. Confidence in the platform is what lets an engineering organization build automation, ship on a schedule, meet compliance obligations, and understand the software it produces. This work will meaningfully improve throughput and scale, and those gains extend a foundation of trust that’s already there.
- Keep people in control of their code. If the system isn’t helping the people and organizations who use it, and isn’t under their control, it isn’t worth building. As agents take on more of the work, the people who own the code can still review, understand, and approve it.
We are building a new GitHub architecture that can scale much more effectively. Our approach centers around core distributed systems design tenets, applied to the concurrency and scale of agentic software development. Our goal is to continue the forward momentum for open-source communities and enterprises around the world who have built their projects with Git and GitHub, while preserving and adapting the features and controls around it to meet the new needs of the agentic era.
A repository that receives many pushes must accept and publish updates quickly. Coordination is valuable when it protects correctness, but too much of it limits write throughput and can turn a busy repository into a bottleneck. Our current architecture is tightly coupled in places it doesn’t need to be, which limits our ability to scale across reads and writes without tough trade-offs. We’re redesigning the system to preserve the coordination that Git semantics require and let everything else proceed independently.
- Coordinate only what needs agreement. The part of a push that truly needs agreement is the reference update itself. Storing the underlying objects, validating object connectivity, and secret scanning are much more work, but most of it can happen in parallel to other writes. That shrinks the critical path of a push to the small step that needs coordination, so the rest of the work no longer delays the acknowledgment.
- Move maintenance off the serving path. Compaction and garbage collection are among the heaviest work a repository does, and today they run on the same hosts that answer live Git requests. In the new architecture, separate workers handle maintenance directly against durable storage. A busy repository can be optimized continuously in the background without slowing pushes and fetches.
Today, complete repository copies on local disks serve both as durable storage and as the layer that answers Git requests. Separating the two lets us scale each one independently.
- Scale reads without adding durable copies. In the new architecture, read capacity comes from lightweight workers that cache data to serve requests. The authoritative copy of the repository lives in a durable storage layer underneath. That way, the platform can absorb large read spikes from CI fan-out, agent fleets, and large clones without adding work to every push.
- Let each layer do one job. Authoritative repository data lives in Azure Blob Storage, which already provides durability and replication at Azure scale. The compute layer is optimized for throughput at the lowest latency.
- Recover faster from failures. When storage and compute are coupled, losing a host reduces both capacity and durability, and recovery means rebuilding a full repository copy. When they’re separate, losing a compute worker is closer to a cache miss: a replacement worker can start serving requests right away and fill its cache from durable storage as traffic arrives.
- Match capacity to demand. Compute workers can be added or removed as traffic changes instead of provisioning for peak load in advance. A repository going through a burst of activity, like a release or a new agent fleet coming online, can get extra capacity for the burst. Once it passes, that capacity goes away.
Together, these tenets allow us to support higher throughput and more concurrent work without abandoning the reliability and controls that our users need.
We’re building an architecture designed to provide the highest throughput and reliability available. Reads and writes scale independently, and the system recovers gracefully from failures. In internal benchmarks, it has delivered up to 35 times higher write throughput, with read capacity that scales on its own to meet demand.
As automated development increases the frequency and concurrency of software change, GitHub will evolve its foundations without trading away the governance and control that teams rely on. We’re already putting that foundation in place. In the next post in this series, we’ll dive deeper into our future architecture and the journey that led us there.
How we fully migrated github.com away from CSS-in-JS.
How we rebuilt the diff surface in the GitHub Copilot app to open a million-line pull request with hundreds of inline review comments.
Why shorter outputs can cost more, and how GitHub Copilot reduces wasted work across the complete coding task.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.