Aspen 发布自托管 Git 服务器，支持大规模并发推送

Aspen 是一个你自己运行的 Git 服务器，专为同时有数百个 agent、CI 任务和人向之推送和拉取的仓库而构建。它通过 HTTP 和 SSH 说普通 Git 协议，所以原版 git 无需任何客户端改动即可使用。它把 pack 存储在对象存储中，把分支历史保存在 PostgreSQL 中，可以在一台机器上运行，也可以在任何云上运行。

状态：pre-alpha。Aspen 已经端到端可用，但尚未通过自身的发布门槛，没有已发布的版本，存储格式仍可能变化。还不要把你不能承受丢失的数据放进去。关于哪些已验证、哪些未验证，详见 Pre-alpha 状态。

在线演示：https://place.reasonmachines.com，一个共享像素画布，每一笔刷都是一次 git push（GitHub 上的镜像）：

git clone https://place.reasonmachines.com/canvas.git

Aspen 的设计遵循 OpenAI 的“Scaling Git at OpenAI”，该文描述了其内部 Git 服务 Pando，并进一步从 Cursor 的“Git at any scale”中汲取灵感，该文描述了其 Git 服务器 Origin 背后的存储。Aspen 是一个独立实现，与 OpenAI 或 Cursor 没有关联；设计来源说明了哪个想法来自哪里。发布文章“Aspen: scaling agentic commits beyond what Git was built for”用交互式图表详细介绍了这一设计。

经典 Git 服务器把每个仓库保存为单个磁盘上的一个目录。每次 push 都会对仓库加锁，每次 fetch 都会让服务器为该客户端构建一个新的 pack。当成千上万的 agent 推送到各自的分支，而 CI 在每次 push 后都 fetch 时，服务器把时间花在锁上，以及一遍又一遍地压缩相同的对象上。

Git 服务器必须在两个方面扩展：许多写入者推送到不同分支，以及许多读取者拉取相同的历史。遵循 Pando 的做法，Aspen 放弃了大多数 Git 服务器视为固定的两项保证：

另外两个选择让它在仓库增长时保持快速：

Aspen 从两篇已发表的介绍文章中汲取灵感，并在一些事情上走自己的路。

OpenAI 的“Scaling Git at OpenAI”（Aaron Friel、Taylor Blau 和 Ted Nyman，2026 年 11 月）描述了 Pando，OpenAI 的 Git 后端。Aspen 是该设计的独立实现，与之不共享任何代码。来自 Pando：

Cursor 的“Git at any scale”（Vicent Martí，2026 年 8 月）描述了 Continuity，Cursor 的 Git 服务器 Origin 背后的存储。来自 Cursor：

这些数字来自发布文章。在一台 8 核服务器上，使用 S3 Standard 和 4 核 PostgreSQL，通过 Aspen 的分支作用域 URL 推送到 git.git 的副本（约 4,500 个文件和 75,000 次提交），Aspen 在五分钟内持续达到每秒 567 次 push，且没有错误。每次 push 在 Git 打印 ok 之前都已进入 S3 和 PostgreSQL。push 的中位耗时为 208 毫秒，第 99 百分位为 314 毫秒，另一个客户端在 push 被确认后中位 30 毫秒就能看到每次 push。

这些设置各不相同：Cursor 的数字来自一个为其自身 monorepo 提供服务的复制集群，其规模该文章没有给出。OpenAI 没有发布 Pando 的 push 速率；它报告 push 中位延迟相比其先前系统降低了近 80%，每天服务近 1 PB 的 Git 数据。

一次 push 经过验证，完成到一个自包含的 pack 中并上传到对象存储；然后一次 compare-and-swap 在元数据存储中移动该分支的 tip。一次 fetch 向元数据存储询问哪些已存储的 pack 覆盖了客户端想要的内容，stitcher 将它们作为一个 pack 流式传输，或者分发 packfile URI 给 CDN。压缩在后台合并小 pack。

它用一个二进制文件、PostgreSQL 和任何兼容 S3 的 bucket 运行，或者在一台机器上用 SQLite 和本地目录运行。镜像模式把 Aspen 放在 GitHub 或 GitLab 前面，所以你可以不迁移就试用它。

目前还没有已发布的二进制文件，所以你需要从源码构建。你需要 git、来自 rustup 的 Rust 工具链（版本固定在 rust-toolchain.toml 中，并在首次使用时安装）以及一个 C 编译器（Debian 和 Ubuntu 上是 build-essential，macOS 上是 Xcode 命令行工具）。构建是慢的部分，在小机器上可能超过十分钟。

git clone https://github.com/reason-machines/aspen cd aspen cargo install --locked --path crates/aspen-cli aspen --version

在一个空目录中启动开发服务器。aspen dev 在一个进程中运行整个服务器，使用 SQLite 和 ./.aspen 下的本地 pack 目录，创建一个名为 demo 的仓库，并且只监听 127.0.0.1:7070，因为任何能访问它的人都可以 push。

mkdir aspen-try && cd aspen-try aspen dev

在第二个终端中，push、克隆回来、推送一个分支并做一个浅克隆：

git init -b main hello && cd hello echo "hello, aspen" > README.md git add README.md && git commit -m "first commit" git push http://127.0.0.1:7070/demo.git main cd .. git clone http://127.0.0.1:7070/demo.git copy git -C copy fsck --strict cd hello git switch -c feature echo "more" >> README.md && git commit -am "on a branch" git push http://127.0.0.1:7070/demo.git feature git ls-remote http://127.0.0.1:7070/demo.git cd .. git clone --depth=1 http://127.0.0.1:7070/demo.git shallow

你应该看到的内容，用你自己的提交 ID 代替 <commit>（输出来自 git 2.39）：

To http://127.0.0.1:7070/demo.git

• [new branch] main -> main Cloning into 'copy'... To http://127.0.0.1:7070/demo.git
• [new branch] feature -> feature <commit> HEAD <commit> refs/heads/feature <commit> refs/heads/main Cloning into 'shallow'...

用 Ctrl-C 停止服务器；它会先完成进行中的请求。

有一件事与其他 Git 服务器行为不同：因为一次 push 只能看到 trunk，所以强制推送需要 git push --force -o force，删除分支需要 -o force（或者使用分支作用域 URL）。要从快速入门中删除 feature 分支：

git push -o force http://127.0.0.1:7070/demo.git --delete refs/heads/feature

Using Git with Aspen 解释了原因。

如果你一遍又一遍地推送同一个分支（比如说，一个 agent 在每次更改后都推送），在推送的克隆中开启 push.negotiate：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）