单仓库承接大量代理并发推送：Git 存储架构要先兑现哪些写入假设

先给结论：本次材料只能确认一件事——这套架构的目标是让数千个 agent 同时向单个仓库推送。至于它如何做到，摘要没有展开。因此这篇文章不描述 GitHub 的实现，而是把这个目标反推成一份假设清单：任何想让单仓库承接大量并发写入的系统，都得先让下面几条成立，否则“并发推送”只是把冲突成本转移给了客户端。

证据边界：材料确认到什么程度#

GitHub Blog 的这篇Inside GitHub's new Git storage architecture，其摘要写道：新架构是为了让数千个 agent 能同时推送单个仓库（GitHub Blog）。除此之外，本次抓取到的正文片段属于同站另一篇关于 star history API 的文章，与 Git 存储无关。所以下文凡涉及具体机制的部分，一律标注为推断或核对项，不作事实陈述。

五条必须先成立的写入假设#

1. 引用更新是原子的比较并交换

Git 的写操作最终落在引用（ref）上：一次推送是把某个分支从旧提交移动到新提交。两个写入者拿着同一个旧值同时提交，只能有一个成功，另一个必须失败并重新基于新值重做。这是比较并交换（compare-and-swap，CAS）语义，属于分布式系统里最基础的假设之一。如果服务端做不到原子，失败形态会很隐蔽：两个 agent 都收到“成功”，但其中一个提交在后续读取中消失。

2. 对象写入是幂等的

Git 对象按内容寻址，相同内容得到相同哈希。两个 agent 推送同一份文件时，底层对象理论上可以只存一份。但“内容相同”不等于“并发写入安全”：需要确认重复写入被当作无操作，而不是报错或产生第二个副本。这是推断，具体行为待核实。

3. 过载时请求可以被拒绝

数千个 agent 同时到达，峰值一定超过瞬时处理能力。没有限流与排队，系统的表现不是“慢一点”，而是延迟随负载上升持续恶化，所有写入者一起受损。可拒绝意味着过载有明确语义——返回错误或进入队列，而不是无限吸收。这是设计建议，不是对现有实现的描述。

4. 冲突收敛，而不是靠重试硬扛

并发写同一分支时，冲突率随写入者数量上升。如果每次冲突都要完整重放，重试次数会接近平方增长。可观测的信号是：并发数翻倍时，平均重试次数怎么变。如果它跟着翻倍甚至更快，说明架构没有消化冲突，只是把成本下推。

5. “单仓库”是产品约束，不是架构必然

需要先问清：为什么必须是一个仓库？如果答案是“用户就是这么组织的”，那是产品需求；如果只是习惯，那么按 agent 拆分支、按业务拆仓库、或者引入提交队列，往往更早到达终点。把产品约束误当成技术约束，会让架构承担不必要的复杂度。

可核对的清单#

表格中的“需要的证据”是核对项，不是对任何厂商的指控。

一个未执行的对照示例#

下面是与 CAS 同构的推送写法，仅用于说明冲突边界，未实际执行，也不代表任何真实服务端行为：

# 未执行示例
# 1. 取到当前分支的基准提交 base
# 2. 在 base 上构造新提交 new
# 3. 仅当远端仍是 base 时才更新；否则失败重来
git push --force-with-lease=refs/heads/agent-work:<base> origin agent-work

# 失败意味着别人先写成功了，必须重新 fetch 并把变更重放到新的 base 上

这段命令的价值在于它把“冲突”显式化：推送失败不是异常，而是这个并发模型的正常输出。架构要做的，是让这个失败足够便宜、足够可重试。

什么时候不该追求单仓库高并发#

• 写入者之间没有共享历史的必要，拆分后冲突自然归零。
• 只需要汇总结果，不需要中间提交可见，那么引入队列或合并流程比放开并发写入更简单。
• 无法保证幂等重试的客户端，一旦放开高并发，重试会放大写入量而不是修复问题。

回到开头：单一目标陈述不足以推出实现。要判断一套 Git 存储架构是否真的扛得住大量代理并发写入，需要拿到引用更新的原子性说明、过载时的拒绝语义、以及冲突率随并发变化的实测数据——这三项在本次材料中均待核实。