告别 NFS 和数据库：用一个二进制文件，把 Git 托管在 S3/GCS 上

walgit 是一款专为「超大仓库」和「极简运维」而生的现代化 Git 服务器。它不依赖本地磁盘存储、不维护数据库、不选举主节点——你只需运行一个 Rust 编译的单二进制程序，指向任意兼容 S3 或 Google Cloud Storage（GCS）的对象存储桶，就能立刻提供完整的 Git 智能 HTTP 协议支持、Web 浏览界面、Git LFS、细粒度权限控制与 Webhook 回调。哪怕你的代码仓库有 200GB packfile、历史提交超百万，只要对象存储可用，walgit 就能稳定服务——而且所有实例完全无状态、可随时扩缩容或重启，零数据丢失风险。

核心功能

零本地状态的分布式 Git 服务：所有仓库数据（包括 packfile、refs、objects）统一存于 S3/GCS 中，walgit 实例仅作为「只读缓存 + WAL 写入器」；机器宕机、扩容、滚动更新均不影响服务连续性，彻底摆脱 NFS 共享文件系统带来的锁竞争与一致性噩梦。
原生智能 HTTP v0/v2 全协议支持：完整兼容 git clone/fetch/push 的所有高级特性——包括 shallow clone、filter-by-path、deepen、sideband-all、atomic push、tag 更新、push options 和 report-status-v2；无需修改客户端配置，开发者仍用熟悉的 git push https://git.example.com/org/repo.git。
Bundle-URI 克隆加速方案：新用户首次克隆或长期离线后同步，不再走慢速 HTTP 流式传输，而是由对象存储直接提供预生成的静态 bundle 文件（按周全量 + 按日/小时链式增量），支持 CDN 缓存、断点续传与并行下载，克隆耗时下降 60%~90%，尤其适合 CI/CD 流水线批量拉取。
真正的 Git LFS 集成支持：LFS 对象同样存于同一 S3/GCS 桶中，walgit 自动解析 .gitattributes 并代理 LFS 上传/下载请求，无需额外部署 LFS 服务器；且因对象存储天然支持高并发，LFS 大文件上传不再成为瓶颈。
免数据库的细粒度权限体系：支持基于 Bearer Token 的轻量认证（亦可扩展 OAuth2），可为每个仓库单独配置推送策略（如仅允许特定分支 push）、设置只读/读写权限，并通过环境变量注入密钥（如 WALGIT_TOKEN_ME），避免敏感信息硬编码在配置文件中。
开箱即用的 Web 界面与 JSON API：内置响应式仓库浏览器，支持 commit 查看、tree 导航、blame、raw 文件下载；同时提供标准化 RESTful JSON API（含 Rust SDK），方便集成到内部 DevOps 平台、审计系统或自动化工作流中。
跨实例强一致的写入保障：通过对象存储的 CAS（Compare-and-Swap）操作实现分布式共识——多个 walgit 实例可同时接收 push 请求，但仅有一个能成功更新 manifest，其余自动重试；无需 ZooKeeper、etcd 或三阶段提交，也无需维护 replica 映射关系表。
历史包（History Pack）优化机制：将 commits/trees 等高频访问的小对象保留在内存或本地 SSD 缓存中，而将体积庞大的 blob objects 始终留在远端对象存储；既保证 git log、git show 的毫秒级响应，又避免单机磁盘被百 GB packfile 塞满。

技术亮点

纯 WAL 架构，颠覆传统 Git 托管范式：walgit 完全采纳 Cursor 提出的「Write-Ahead Log + Object Store as Source of Truth」设计（详见其经典文章《Git at any scale》），将每次 push 转化为不可变的 WAL 条目（如 push-20240520-abc123），再通过原子 manifest 更新对外可见；这使得「仓库比机器还大」成为常态而非异常，彻底绕开本地磁盘 I/O 和文件系统一致性难题。
Rust 实现的极致可靠性与性能：基于 Tokio 异步运行时构建，充分利用现代 CPU 多核能力；所有网络请求、HTTP range 分片读取、CAS 操作均以 zero-copy 方式处理；实测在 4c8g 云主机上可稳定支撑千人级团队对 TB 级 monorepo 的日常开发协作。
远程 reader 设计，突破单机容量限制：当某次 git fetch 需要读取远端 packfile 时，walgit 不尝试将其下载到本地再 serve，而是直接发起 HTTP Range 请求从 S3/GCS 流式转发，配合 ETag 缓存与 304 Not Modified 响应，让「仓库大小 > 机器内存」不再是架构障碍。
Compaction 服务解耦，降低单点压力：packfile 合并（repack）不是由每个实例独立执行，而是由随机获得 lease 的实例完成，并将结果以新 WAL 条目形式发布；其他实例仅需下载 compacted pack 即可，避免重复计算与资源争抢，显著提升大规模仓库的长期维护效率。

适合哪些人用

walgit 特别适合以下两类技术团队：

拥有巨型 monorepo 的中大型研发组织：例如某自动驾驶公司使用 150GB+ 的单一 Git 仓库管理全部传感器驱动、算法模型与仿真平台代码，过去依赖自建 NFS + Gitolite，频繁遭遇挂载超时与 push 失败；迁移到 walgit 后，用 3 台 4c8g ECS + 阿里云 OSS，实现了 99.99% 可用性与平均 200ms 的 push 延迟。
追求基础设施极简化的初创或 SaaS 服务商：某低代码平台厂商需为数千客户快速开通专属 Git 仓库，但不愿维护 PostgreSQL、Redis、Nginx、Git daemon 等一整套组件；采用 walgit 后，仅需部署一个容器（含配置文件与环境变量），搭配腾讯云 COS，即可实现全自动仓库创建、权限隔离与审计日志导出。

快速上手

只需三步，5 分钟内启动你的第一个 walgit 服务：

准备一个 S3 兼容对象存储桶（如 AWS S3、MinIO、阿里云 OSS、腾讯云 COS），并确保网络可达；
创建配置文件 walgit.toml（示例已适配国内云厂商）：

[server] listen = "0.0.0.0:8080" public_url = "https://git.yourcompany.com" auto_create_on_push = true


[server.auth]
mode = "token"
anonymous_read = false
tokens = [{ principal = "admin", token_env = "WALGIT_TOKEN_ADMIN", write = true }]
[store]
backend = "s3"
bucket = "your-walgit-bucket"

[store.s3] endpoint = "https://oss-cn-hangzhou.aliyuncs.com" region = "oss-cn-hangzhou"

生成令牌并启动服务：
WALGIT_TOKEN_ADMIN=$(openssl rand -hex 24) walgit serve --config walgit.toml

然后即可用标准 Git 客户端操作：
git -c http.extraHeader="Authorization: Bearer $WALGIT_TOKEN_ADMIN" push https://git.yourcompany.com/myproject.git main

同类对比 / 注意事项

vs Gitea/GitLab：walgit 不提供 Issue、PR、CI 等 DevOps 功能，专注做「纯粹的 Git 协议层」；它没有数据库依赖、无后台任务队列、不存储用户信息，因此资源占用仅为 GitLab 的 1/20，但也不适合需要完整协作平台的团队。
vs GitHub Enterprise / GitLab Self-Managed：walgit 放弃了「强一致性本地副本」路线，转而拥抱云原生对象存储；这意味着它无法支持某些需要毫秒级 ref 更新的极端场景（如高频 force-push 测试），但换来了近乎无限的水平扩展能力与零运维复杂度。
注意事项：首次 push 后需等待约 1–2 秒 manifest 更新才可在 Web 界面看到仓库；建议搭配 CDN 缓存 bundle-uri 静态资源；若使用 MinIO，请确保启用 versioning 并关闭 replication 以避免 WAL 冲突。