feder-cr/git-ai

如果你正在协调多个编程 Agent，每个 Agent 只改几个文件就希望立刻落地，gitai 值得关注；但它还不是能直接替换 Git 的成品，而是一个年轻的 0.x 服务端，构建门槛不低。

解决什么问题

编程 Agent 往往在几秒内完成一个小任务就立刻提交，而传统 Git 托管假设的是人类先克隆、工作数小时、最后推送一次。当几十个 Agent 同时往同一分支落地时，完整克隆和合并队列会成为瓶颈，每个 Agent 都要自己 rebase 并重试比较并交换。gitai 改动的正是这一环节：服务端把收到的改动 rebase 到当前 tip，再用比较并交换落地，并把同一分支上的并发落地批量合并成一次引用更新。它想达到的结果是更多 Agent 改动成功落地、重试更少，而且不需要中央合并队列。

有什么不同

它的设计参考 Anthropic 公开描述的 Scion 系统，README 说明 Scion 是 Anthropic 内部系统、未对外发布；gitai 是该公开设计的独立实现，采用 MIT 许可，与 Anthropic 无隶属关系。服务端负责 blame、路径历史、祖先关系和代码搜索，并按提交缓存为派生数据。客户端保持在线，只拉取需要的对象，所以 graft CLI 可以只具现稀疏路径，不必完整克隆。AI 解决冲突的功能不绑定模型供应商，README 称服务端从不调用语言模型。

代价在架构上：这是以服务端为中心的系统，不是给普通 Git 加个插件。采用它意味着要运行 gitai 服务端，可能还要跑缓存守护进程，而且 1.0 之前接口仍可能变化。作者的基准测试显示落地吞吐有明显提升，但数据来自一台 16 核机器、两次运行，而且同一页面注明那次对比关闭了冲突解决器，因此应把它当作作者自报结果，而不是普遍保证。

谁值得试

它适合已经在用大量并行编程 Agent 操作共享分支、并且愿意自己运维版本控制服务的团队。也适合想研究 Scion 设计的开发者，因为项目提供了设计文档，可以运行、阅读或参与贡献。

如果只是为人类团队提供一个普通 Git 托管，或者期待成熟稳定的产品，就不太合适；README 标注版本 0.4.0，接口可能变化。如果没有准备运行服务端，文档中没有轻量路径：初始设置需要构建服务端和 CLI，运行自己的实例还要改配置文件。

使用条件与边界

从源码构建需要 Linux 或 macOS、Go 1.26、C 工具链、Meson 和 Ninja，因为构建过程会编译一份内置的 Git。这条依赖链让初始安装比普通的 Go 单文件程序重得多。日常运行还要维护服务端、可选的缓存层和配置文件。

项目从 Gitaly 分支而来，上游 Gitaly 的 RPC 仍可继续工作，但非 MIT 的 ee/ 目录不包含在内。存储可以迁到数据库和对象存储，流程是先 shadow 再 authoritative，细节见存储文档。已知缺口（例如 pack 的垃圾回收）列在 LIMITATIONS.md 中，长期存放重要仓库前应先查看这些限制。

HotRepo 点评

2026-10-25，gitai 以 990 个总星数出现在新项目榜第 3 名，距离 HotRepo 开始追踪它只有两天。这条记录能说明当时有关注度，但不足以判断持续趋势，当前趋势证据不足以下结论。动手之前，建议先读 LIMITATIONS.md 和存储指南，确认存储路径和已知缺口符合你的仓库需求。