把 Git 仓库放进对象存储：单二进制、无数据库的托管架构
Git 仓库的 packfile 让托管变得困难：每次操作都要对 GB 级数据随机访问，网络文件系统承载不了，大规模方案又依赖数据库、固定副本集和常驻机器。walgit 把对象存储中的写前日志作为唯一事实来源、磁盘仓库只当缓存，用一个二进制提供 push、fetch、bundle-uri 克隆和 LFS，让仓库可以大于运行它的机器。
目标用户
需要自托管 Git 服务、想托管大型仓库或 monorepo、但不愿维护数据库、固定副本集和常驻服务器的小团队、独立开发者与中小公司。
潜在需求
一种让 Git 仓库以对象存储为唯一事实来源、本地只做缓存的托管方式：无需数据库和 leader，任意实例可接受 push，读取靠条件 GET 保持一致；clone 和追赶更新通过 bundle-uri 静态文件走出服务器，从而在小于仓库的机器上托管大仓库。
发生场景
大型仓库的包文件按'更小'而非'顺序读取'设计，每次 git 操作都是对 GB 级数据的随机访问；放在网络文件系统上表现灾难性，'仓库直接放 NFS'被证明失败。能工作的方案（GitHub Spokes）要求本地 NVMe、数据库、固定副本集和常驻机器；当仓库本身大于可用的单机实例时，托管 monorepo 尤其受限。
来源证据
Git 的 packfile 按体积小而非顺序读设计，每次 git 操作都是对 GB 级数据的随机访问；在笔记本上靠页缓存没问题，在网络文件系统上是灾难性的，'直接放 NFS'的方案在大型托管商都失败了。
large binary packs laid out to be small, not to be read in order; every git operation is a random walk over gigabytes. That is fine on a laptop with the file in page cache and catastrophic over a network filesystem, which is why "just put the repositories on NFS" failed at every large host that tried it. The design that survived (GitHub's Spokes) keeps real repositories on local NVMe so upstream `git` does the work, and replicates at the packfile level with strict consistency — paid for withhttps://github.com/tobi/walgit
为什么值得留意
它把主流 Git 托管中被视为必需的基础设施（数据库、副本集、三阶段提交）替换成一个对象存储 bucket 和 CAS 写日志，显著降低自托管大型仓库的运维门槛；同时对'仓库大于机器'的场景给出了具体机制（remote reader、history pack、bundle-uri），是一套值得独立开发者跟进验证的架构取舍。
已有方案
- 网络文件系统（NFS）直接存放仓库——在大型托管场景已被证明失败
- GitHub Spokes：本地 NVMe 保留真实仓库，packfile 级复制，三阶段提交 + 数据库 + 固定副本集
- Cursor 的 Continuity：对象存储 WAL 作为唯一事实来源（内部系统，walgit 以其为蓝图）
未满足部分
- NFS 直放仓库在大型托管场景已被证明失败，缺少轻量替代
- 现有大规模方案依赖数据库、固定副本集和常驻机器，小团队难以承担
- packfiles 大于实例的 monorepo 在小机器上没有现成的托管方式
可能延伸 · 模型推测
- 把 WAL 的完整溯源能力做成时间点回放与审计报告服务
- 将同样的'对象存储 WAL + 缓存'架构复用到容器镜像或机器学习数据集等大文件分发
- 基于 bundle 产物的离线镜像与冷备服务
- 为 CI 提供基于条件 GET 的仓库只读代理，减少重复克隆
目前未知
- 项目创建于 2026-08-23，暂无独立用户采用或性能报告，README 能力未被第三方验证
- 目标用户（小团队/独立开发者）由架构描述推断，材料没有点名具体用户
- 与 Gitea/GitLab 等常见自托管方案的对比在材料中未出现
- 未提供真实负载下的带宽、存储成本与一致性表现数据
继续核实
- 小团队自托管 Git 时，仓库超过单机磁盘或内存的情况有多常见？
- 现有自托管方案在大型 monorepo 上的失败案例有哪些具体表现？
- 对象存储作为唯一事实来源在 git 高频读写下的延迟和成本是否可接受？
- 除 walgit 外是否还有其他项目在实现'对象存储 WAL 即仓库'？