当我们从零设计一个 Git 托管平台时，首先需要明确一个基本事实：Git 本身是一套分布式版本控制系统，而非一个网络服务。构建托管平台的核心任务，是在 Git 之上叠加认证、授权、元数据管理、代码审查和持续集成等能力，同时保持与 Git 原生协议的兼容性。这种 “协议优先” 的思维，正是 Mat Duggan 在其「If I Could Make My Own GitHub」中所倡导的设计哲学：将校验环节前移，使平台更贴合开发者的实际工作流，而非将 Git 仅视作一个存储后端。
Git 协议层的实现与选型
一个生产级的 Git 托管服务，在协议层面通常划分为三个层次：传输层、Git 服务层和存储层。传输层负责客户端与服务器之间的通信，最常用的两种协议是 SSH 和 Smart HTTP。SSH 协议的优势在于它复用操作系统现有的用户体系和密钥认证机制，客户端通过 SSH 通道直接在服务器上执行 git-upload-pack 或 git-receive-pack 进程，整个过程无需额外的认证层。Smart HTTP 则将 Git 协议封装在 HTTP 请求中，通过 git-http-backend 这个 CGI 程序处理，服务器在收到 HTTP GET 请求时执行 git-upload-pack，收到 POST 请求时执行 git-receive-pack。这种方式的突出优点是防火墙友好、兼容标准 Web 认证（如 OAuth、LDAP），且可以在 Nginx 或 Apache 层统一终止 TLS。
在工程实践中，一个推荐的基础架构是：Web 前端（如 Nginx）终止 TLS 并处理用户认证，将以 /git/ 开头的请求转发给 git-http-backend 处理，SSH 认证则通过 SSH 公钥验证后直接调用 Git 进程。两者可以共存于同一平台，为不同场景提供灵活选择。对于内部部署场景，建议 SSH 端口配置为非标准端口（如 2222）以降低暴力破解风险，同时在 SSH 配置中强制使用密钥认证并禁用密码登录。HTTP 服务的超时参数建议设置为 keep-alive 60s、read timeout 300s，以应对大型仓库首次克隆时的高延迟。
存储后端的架构设计
Git 的原生存储是内容寻址的对象数据库，位于 .git/objects 目录中，包含 blob、tree、commit 和 tag 四种对象类型。当对象数量增长时，Git 会自动将多个对象打包成 packfile 以节省空间并优化网络传输。一个自建平台在存储层面需要做的核心决策，是选择直接使用文件系统存储 bare repository，还是构建自定义的对象后端。
对于中小规模部署（数百个仓库、数百名用户），直接在本地磁盘或网络文件系统（如 NFS、CephFS）上存储 bare repository 是最简单且最可靠的选择。Git 自身的 packfile 机制已经足够高效，无需额外抽象。但当规模进一步扩大时，存储层往往成为瓶颈。此时可以考虑将对象存储抽象化，使用 S3 兼容的对象存储（如 MinIO、Ceph RGW）作为 Git 对象的持久层，Git 进程通过自定义的 git config core.fsmonitor 和 core.untrackedCache 优化本地性能，而对象上传下载则通过 HTTP API 完成。一个实用的工程参数是：将大文件（>50MB）通过 Git LFS 单独存储，并在 LFS 服务器前端配置 Redis 缓存层，将热点对象的访问延迟从毫秒级降低到亚毫秒级。
元数据存储（用户、仓库列表、权限、审计日志）则应与 Git 对象存储解耦，使用传统的关系型数据库（如 PostgreSQL）或键值存储（如 etcd）管理。一种经过验证的架构是将仓库的物理路径作为元数据的一条记录，通过外键关联到用户权限表和项目设置表，这样可以在不影响 Git 对象的情况下独立扩展元数据服务。
CI/CD 流水线与代码审查的工程实践
在协议层和存储层之上，托管平台需要提供代码评审和持续集成的能力。Mat Duggan 在其设计愿景中提出的一个关键洞察是：校验应该前移。传统 Git 平台将质量检查放在推送之后，由 CI 系统执行，而一个重新设计的平台可以在推送之前（即本地 git push 时）就运行预推送钩子（pre-push hook），让开发者更快获得反馈。实现这一点的工程做法是：在服务器端配置 update 钩子，在 ref 更新前执行 lint、格式检查或单元测试的超集，耗时通常应控制在单次提交 30 秒以内，否则会显著阻塞开发者的推送体验。
代码审查层面，一个有价值的改进是支持 “非二元审查状态”。传统的 Approve / Request Changes 两级模式过于粗粒度，一个更实用的设计是引入 “May Merge with Comments” 或 “Pending Follow-up” 等中间状态，允许审查者表达 “代码可以合入，但我希望后续有人处理这些遗留问题” 的意愿。这种状态可以存储在元数据数据库中，通过 Web UI 展示为不同颜色的标签。
对于 CI 流水线，一个可落地的架构是采用容器化的执行环境（如 Kubernetes 上的 ephemeral pod），每次构建启动一个隔离的容器，构建完成后立即销毁。构建缓存策略推荐使用两层缓存：本地磁盘缓存存放编译产物（命中率通常在 60%~80%），远程缓存（如 S3）存放跨节点的共享产物。构建超时参数建议根据项目类型分级设置：快速单元测试 5 分钟、集成测试 15 分钟、完整发布构建 30 分钟，超时后自动终止并回滚资源。
规模扩展与高并发挑战
当平台承载数千个仓库和数万名并发用户时，架构的可扩展性成为关键。水平扩展的核心思路是将 Git 协议处理节点与存储节点分离：协议节点无状态部署，通过负载均衡（如 HAProxy 或云负载均衡器）分发请求；存储节点则通过分布式文件系统或对象存储服务提供一致的数据访问。对于读多写少的场景，可以在协议节点前增加一层 CDN 或缓存代理（如 Varnish），将频繁访问的 packfile 和对象缓存至边缘节点。
一个常被忽视的扩展细节是 ref 广告（ref advertisement）的性能。当仓库包含数万条分支和标签时，服务器需要在每次 fetch/push 之前将完整的 ref 列表发送给客户端，这一过程的复杂度为 O (n)。优化的工程做法是对 ref 进行分层索引，按名称前缀或仓库分组建立倒排索引，将典型场景下的 ref 查询时间从数百毫秒降低到十毫秒以内。
综合来看，从零设计一个自建 Git 托管平台的核心思路可以归纳为：尊重 Git 自身的协议与存储模型，在此基础上叠加认证、授权和协作功能；将质量检查前移到开发者本地和推送阶段；通过容器化实现可扩展的 CI 流水线；并在架构层面解耦协议处理、对象存储和元数据管理，使其能够独立演进和扩展。这些设计原则和工程参数，为构建一个轻量、可定制且高效的自有代码托管平台提供了可行的起点。
资料来源：Mat Duggan「If I Could Make My Own GitHub」；Git 官方文档 git-http-backend、pack-protocol；GitHub Engineering「Git's database internals I: packed object store」。