当我们讨论自托管 Git 平台时，谈论的往往不是「能否搭建」，而是「如何在有限资源下获得与 GitHub 相近的开发体验」。Mat Duggan 在其关于「如果我要再造一个 GitHub」的思考中指出了一个关键事实：现代 forge 平台已经与 Git 客户端的实际使用方式严重脱节。大多数团队将 Git 仅视为「推拉代码的通道」，而把 Pull Request、CI/CD、权限管理、发布管理等核心功能全部寄托在 forge 之上。这种工作模式的转变意味着，自托管平台的设计必须从「如何更好地管理 Git 仓库」转向「如何更好地管理开发工作流」。本文将从存储后端选型、工作流抽象设计、成本模型三个维度，探讨自托管 Git 平台的架构设计权衡。
存储后端：S3 兼容对象存储的事实标准
自托管 Git 平台的存储层通常分为两个部分：Git 仓库元数据（ commits、trees、blobs 的压缩对象）与大文件存储（LFS、构建产物、发布包）。传统方案将两者均放在本地文件系统，但随着仓库规模增长，这种架构会遇到明显的 I/O 瓶颈。2025 年后的主流趋势是将大文件与构建产物迁移至 S3 兼容对象存储，让 Git 进程专注于元数据操作。
在存储后端选型上，有三个主要选项需要评估。MinIO 是最成熟的通用方案，性能接近云端 S3，支持 Kubernetes 原生部署，但其 AGPL-3.0 许可证在 2025 年后导致社区版需要自行编译，增加了运维复杂度。对于追求开箱即用的团队，Garage 是一个值得关注的替代品 —— 这是一个 Rust 编写的轻量级对象存储，单节点部署极为简单，运维门槛显著低于 MinIO，适合中小规模团队将 12 台树莓派组成一个分布式存储集群的使用场景。SeaweedFS 则在高 I/O 场景下表现突出，其针对海量小文件优化，在代码审查频繁、PR 创建密集的工作流中更有优势。架构选型的推荐参数如下：对于 50 人以下的开发团队，单节点 Garage 足以支撑日常开发；若团队规模超过 200 人或每日 CI 运行次数超过 500 次，建议采用 MinIO 或 SeaweedFS 以获得更好的并发处理能力。
需要特别注意的是，无论选择哪种后端，都应通过 S3 协议进行集成而非直接挂载文件系统。Gitea、Forgejo 和 GitLab 均支持在配置文件中指定 S3 端点，这意味着存储层可以在不影响应用层的情况下独立扩容。一个实用的监控参数是对象存储的 PUT/GET 请求延迟 —— 若 P99 延迟超过 200ms，就应当考虑升级存储节点或切换后端方案。
工作流抽象：从 Git 中心到流程中心
Mat Duggan 在其思考中提出的最尖锐批评之一，是现代 forge 将 Git 本身与开发者日常工作完全割裂。大多数开发者的一天是这样的：本地写代码、提交、推送，然后在 forge 界面上等待 CI 结果、提交 PR、等待审批。这个循环中，Git 客户端几乎只负责「提交」和「推送」两个动作，其余全部发生在浏览器中。这导致了几个关键的架构问题需要重新思考。
预提交验证前置化 是第一个需要解决的流程问题。传统的做法是本地 commit 后推送至远程，由 CI 在远程运行测试，失败后再打回修改。这种反馈循环的周期太长，尤其对于大型项目可能需要数十分钟才能获得一次测试反馈。更优的架构是在本地 commit 之前就触发远程验证 —— 用户执行 commit 操作时，forge 后端自动启动一个临时构建任务，在数秒内返回 lint 和单元测试结果，用户据此决定是否真正提交。这种模式需要 forge 提供「预提交钩子即服务」的能力，推荐的技术参数是：验证任务超时时间设置在 60 秒以内，超过则自动降级为传统推送后验证。
审批粒度的精细化 是第二个关键改进点。当前的 Pull Request 审批几乎是二元的 —— 要么通过，要么拒绝。Gerrit 模型的「弱批准」（weak approval）机制更有助于真实团队协作：维护者可以标记「批准但需要后续处理」，将技术债务显式化而非隐式忽略。在实现层面，这意味着需要在 PR 状态机中增加一个「有条件批准」状态，并要求在合并前满足特定标签或时间窗口条件。
分级审批规则 则是第三个必要的架构决策。并非所有代码变更都需要同等程度的审查 ——LLM 可以对低风险的配置变更或文档更新给出置信度评估，对于这些场景应当允许维护者一键合并。推荐的做法是引入「风险评分」维度：由 LLM 对变更进行初步分析，若变更仅涉及特定文件类型（如 .md、.yml、.json）且 diff 行数低于阈值，则标记为「低风险」，允许配置自动化合并路径。
成本模型：从小规模起步，向分布式演进
自托管平台的核心成本结构与商业 GitHub 有本质区别。商业平台采用「按用户数收费」的 SaaS 模式，用户为平台品牌、可靠性和功能丰富度付费；而自托管的成本更多体现在基础设施和运维人力上。理解这一点是做出正确架构决策的前提。
存储成本 是最可控的部分。如前所述，采用对象存储后，大文件成本可以精确量化 —— 以 Garage 为例，每 TB 月存储成本大约是自建硬件成本的 1/3 到 1/2（取决于硬件配置和电费）。更关键的优化在于浅克隆策略：Duggan 在其思考中提到的「本地副本不应包含完整历史」是一个革命性的理念。实现方式是配置 Git 的 partial clone 和 fetch 协议，允许客户端默认只拉取最近 30 天的提交历史，完整历史按需从对象存储加载。这不仅大幅降低了首次克隆的网络开销，还能将存储成本从「为所有历史买单」转变为「为活跃历史买单」。
计算成本 主要来自 CI/CD 构建。GitHub Actions 的按分钟计费模式在自托管场景下需要重新设计。一个可行的策略是引入「构建资源池」概念：维护一个可伸缩的构建节点集群（可以是虚拟机、容器或 Lambda 函数），通过任务队列分发构建任务。对于中小规模团队，8 核 32GB 的构建节点能够支撑每日 200 次构建；若构建频率更高，则需要考虑构建任务的分流和缓存策略。
运维成本 是最容易被低估的部分。GitLab Enterprise 和 Gitea 的运维复杂度差异巨大 —— 前者是一套完整的 DevOps 平台，后者则聚焦于代码托管本身。Duggan 在其思考中提出的「最小托管单元」理念值得重视：与其运行一个庞大的单体 forge，不如设计多个轻量级的实例，通过联邦协议或账户映射实现互联。这种架构的运维优势在于：单个实例的故障不会影响全局，一个由 12 台树莓派组成的「组织级」forge 完全可行，且单点故障影响范围可控。
架构决策检查清单
在规划自托管 Git 平台时，建议围绕以下参数进行决策：存储后端优先选择 S3 兼容方案，团队规模 50 人以下用 Garage，200 人以上用 MinIO 或 SeaweedFS；工作流层面优先实现预提交验证和分级审批规则，将反馈周期从「分钟级」压缩到「秒级」；成本模型上采用浅克隆策略降低存储成本，并通过任务队列实现构建资源的弹性伸缩。如果团队对功能丰富度要求不高，Forgejo 配合 Garage 是最具性价比的组合；如果追求与 GitHub 相近的体验，GitLab Self-Managed 配合 MinIO 是更稳妥的选择。
无论选择哪条路径，关键在于认识到自托管不是「更便宜的 GitHub」，而是一种以架构可控性为优先的产品形态。当团队掌握了存储层、工作流层和成本层的主动权，才能真正让工具服务于开发而非被工具所束缚。
参考资料
- Mat Duggan, "If I Could Make My Own GitHub"（2026）
- Self-Hosted Weekly, "S3-Compatible Object Storage Comparison 2025-2026"