上万个 agent 同时 push 同一个仓库：Git 存储架构该核对哪些并发写入假设

简短回答：在本次材料范围内，能核对的只有一句话——GitHub 在 2026 年 11 月 5 日的博文中称，其新的 Git 存储架构是为让数千个 agent 同时向单个仓库 push 而构建的。至于它靠什么做到，材料只给了标题与摘要。所以下面不猜它的分片方式或锁设计，而是给出评估任何“支持高并发 push”的 Git 存储时应当逐条核对的写入假设。

先把来源的边界说清楚#

来源是 GitHub Blog 的 Inside GitHub’s new Git storage architecture，来源日期 2026-11-05。摘要的表述是：该架构使数千个 agent 可以同时向单个仓库 push。

本次材料仅含标题与摘要，未含正文。因此下面这些问题在本文中一律标为待核实，而不是“官方没有说明”：引用存储用什么后端、锁粒度多大、对象去重与打包策略、限流阈值、错误码与重试建议。摘要与标题也不构成对正文的完整阅读，不能拿它反推实现。

数量级也要对齐：摘要写的是 “thousands”（数千），中文标题里的“上万”是传播中的表述。两者不是同一量级，把“上万”当作来源事实引用并不稳妥。

把“并发写入”拆成四类可核对假设#

1. 引用更新是不是以旧值为条件的原子替换

一次 push 的语义核心是“旧 ref 值 → 新 ref 值”。多个 agent 同时推同一分支时，正常预期只有一方成功，其余收到 non-fast-forward 一类拒绝。要核对的是：服务端是否真的以旧值为前提提交更新，而不是“最后写入者获胜”。后者不会报错，只会静默丢提交——这是高并发场景里最难发现的一类故障。

2. 对象写入与引用可见性的先后顺序

要核对：在对象全部落盘并被校验之前，引用是否可能已经对外可见，从而让读取方看到悬空引用；接收端是否存在临时隔离区、其清理时机是什么。这一条决定了“读到一半的 push”会不会被别的 agent 观察到。

3. 钩子与策略检查是否变成串行点

pre-receive 钩子、分支保护、签名校验都要在每个 push 上跑一遍。并发量上来后，真正先撞墙的往往不是存储，而是这些检查共享的锁或全局配额。要核对：检查是按仓库串行还是可并行、超时如何返回、超时算失败还是排队。

4. 失败与重试语义

要核对：失败响应能否区分“冲突”“限流”“临时错误”；重试是否幂等；一个 push 携带多个 ref 时，是全部生效还是一律回滚（对应 --atomic 的语义）。agent 场景下重试是自动的，语义不清就会放大重复写入。

核对表#

一个最小验证，别先信文档#

下面只是示意核对方法，未执行，也未针对任何真实服务运行。域名与路径为占位。

# 未执行示例：需自建测试仓库，不要对生产仓库做并发压测
git clone --bare https://example.com/OWNER/REPO.git repo.git
# 两个终端同时向同一分支推送不同提交，观察第二方的返回
git push origin HEAD:refs/heads/main
# 再测多 ref 的情况，确认是否整体回滚
git push --atomic origin HEAD:refs/heads/a HEAD:refs/heads/b

这个实验只能回答“冲突是否被正确拒绝”，回答不了锁粒度与隔离区策略。要验证后者，需要服务端日志或官方文档，二者本次材料都没有。

边界条件#

• 单仓库高并发 push 与多仓库并发 push 是两类负载，材料未作区分，结论不能互相搬运。
• “能承接高并发”不等于“延迟不变”，后者需要可核验的测量记录，本文不提供任何数字。
• 如果服务端对 push 做了排队，冲突率会下降但尾延迟上升——这是取舍，不是优劣。

结论收窄到一句：在只拿到标题与摘要的情况下，能做的不是评价这套架构，而是把上述四类假设写成可验证的问题，逐条向服务提供方或自己的压测环境要答案。