GitHub 新架构：单仓库支持每秒数千次写入
GitHub's new Git storage architecture
在 GitHub Universe 大会上，我们发布了全新的 Git 存储架构，专为应对 Agent 驱动的开发浪潮而生。这套名为 Project Rubicon 的系统，通过解耦存储与计算，实现了每秒 7200 次推送和 5000 个并发 Agent 的惊人吞吐量。核心设计在于利用 Azure Blob Storage 存储不可变的 Git 对象，同时通过 Ref-CAS 服务处理引用更新，确保在极低的延迟下维持数据一致性。这意味着，随着 AI 代理全天候并行工作，单个仓库的写入压力将不再是瓶颈，GitHub 正为未来数亿开发者构建坚实的底层基础设施。
Git 对象是不可变的且由其内容命名，这意味着两个写入者可以同时存储它们，而无需就任何事项达成一致。
HN 评论区
20- yakkomajuri
如果我没理解错的话，这算是（非常扎实的）未来规划，但并不能解决当前的宕机问题？
从标题和开头内容来看我原本也是这么想的，但随后他们又提到，横向扩展技术基本上是从现有架构沿袭下来的（而问题似乎就出在这里？），这主要是为了帮助他们所谓的“垂直扩展”（即仓库内的可扩展性）。他们紧接着也承认，目前最活跃的仓库在今天只会收到最多几十次写入的短暂突发流量。
所以这看起来确实是对近期未来非常有用的规划，可能有助于防止更多问题，但似乎并不是为了解决当前的问题。我理解对了吗？
当然，无论怎样，这类改进总是有用的。我完全没有在贬低。
- pksunkara
其中大部分内容类似于 https://enroute.sh 已经在做的 Git 扩展工作。https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
- jxramos
Agent 扩展绝对是行业关注的焦点，我很好奇 GitHub 的人会对 https://www.anthropic.com/research/redesigning-source-contro.... 这篇内容作何回应。这是一篇很有趣的文章，让人退一步从第一性原理重新思考源代码控制，并针对这个新范式下真正重要的特性重新权衡取舍。