源代码托管怎么选：Gerrit、GitLab、GitHub 与 Gitea

源代码托管平台看起来都差不多：建仓库、提变更、跑流水线、开 Issue。于是选型很容易变成截图对比：谁的功能更多、界面更新、免费额度更大。等真正迁移，才发现 Git 仓库只是最容易搬走的那一层，代码审查记录、流水线、权限、制品、机器人和团队习惯早已长在平台里面。

Gerrit、GitLab、GitHub 和 Gitea 的根本区别，不是四套网页皮肤，而是四种协作模型：Gerrit 把严格审查当作提交代码的入口，GitLab 把仓库放进一体化 DevSecOps 平台，GitHub 把代码放进公开协作网络，Gitea 则把轻量自托管与控制权放在前面。

所以我不会先问「谁最好」，而会先问：代码能否放在公有云？审查是建议还是门禁？需要多少 CI/CD 和安全治理？谁来维护平台？公开生态是否重要？这几个问题答完，候选通常已经少了一半。

一、先把「托管」拆开

Git 负责对象、提交、分支与传输协议，平台则在它上面叠了许多组织状态：

• 身份、团队、仓库权限和分支保护；
• Pull Request、Merge Request 或 Change 的讨论与批准；
• Issue、看板、里程碑、Wiki 和通知；
• CI/CD、Runner、环境、密钥与部署审批；
• 包、容器镜像、构建产物和依赖代理；
• 代码搜索、安全扫描、审计与合规记录；
• Webhook、应用、机器人和第三方集成。

裸仓库用 git clone --mirror 就能复制，后面这些数据却各有 API、权限和语义。迁移 GitHub Actions 到 GitLab CI，不是把 YAML 文件改个名字；从 Gerrit 的 Patch Set 迁到 Pull Request，也不只是导入评论。平台锁定主要发生在协作流程，而不是 Git 数据本身。

这也解释了为何「都支持代码审查」没有太大信息量。审查对象是什么？谁可以批准？新补丁会不会使旧批准失效？流水线结果是不是提交条件？能否表达多个团队的组合规则？这些细节会直接改变研发日常。

二、四个平台，四个重心

Gerrit：先通过门，再进入主线

Gerrit 的核心对象是 Change。开发者通常把提交推送到 refs/for/<branch>，服务器据此创建待审变更；后续修订作为新的 Patch Set 追加到同一个 Change。审查者可以在诸如 Code-Review、Verified 等标签上投票，Submit Requirements 再用表达式决定变更何时允许提交。

这个模型很适合「每一个进入主线的提交都应独立审查」的组织。提交历史可以保持整洁，机器人验证与人工批准都是明确门禁，权限和规则能做得很细。Android 等大型工程形成的使用方式，也说明它擅长处理高纪律、集中式主线开发。

代价同样明显。Change-Id、Patch Set、特殊推送引用和标签投票都需要学习。习惯 GitHub 的开发者第一次看到 Gerrit，容易觉得自己不是在提代码，而是在办理通关文牒。它的 Issue、项目管理、制品和 CI 也不是核心强项，常需 Jenkins、Zuul、Gitiles 或其他系统配合。插件可以扩展能力，但插件兼容、升级和运维会落到自己身上。

因此，Gerrit 更准确的定位是代码审查与提交门禁系统，而非开箱即用的研发全家桶。若组织确实需要强制、细粒度、提交级审查，这种专注很值钱；若只是十个人写一个普通 Web 应用，它可能把流程严肃得超过问题本身。

GitLab：把工具链收进一栋楼

GitLab 以 Merge Request 为协作中心，把代码差异、讨论、审批、流水线状态与可合并性放在同一处。Issue、规划、CI/CD、Runner、包和容器注册表、安全扫描、环境与发布继续向外延伸。它既有 SaaS，也有 Self-Managed 和 Dedicated 路线，适合希望数据留在自己网络、又不想拼接十几个系统的组织。

一体化的好处是身份、权限和审计可以贯穿流程。一次合并能够关联需求、流水线、镜像、部署环境与安全结果，减少系统间同步。对受监管行业或内网研发，这种统一不是界面整齐，而是合规证据更容易闭环。

一体化也意味着平台更重。自托管 GitLab 要规划数据库、对象存储、备份、Runner、监控、升级与高可用；团队规模不大时，维护平台的人可能比维护业务的人更忙。部分高级审批、安全和治理能力属于更高商业层级，不能只看社区版功能表后假设全部可用。GitLab 功能很多，但每启用一项都带来配置与升级责任。

我的判断是：如果公司明确需要自托管的一体化研发平台，并且有平台团队承担生命周期，GitLab 通常是四者中最完整的答案。若只是想放几个私有仓库和跑简单测试，它可能像为了热一杯牛奶买了整套餐厅后厨。

GitHub：代码也是一张社交图谱

GitHub 的优势首先是网络效应。公开项目、贡献者身份、Fork、Pull Request、Issue、Release、Marketplace 和搜索共同组成开发者协作入口。开源项目在这里不仅托管代码，也被发现、讨论、引用和招聘者看见。对公开项目而言，要求贡献者注册一个他们大概率已有的账号，本身就在降低门槛。

私有研发方面，Pull Request、Rulesets、Actions、Packages、Codespaces 与安全产品形成了成熟平台。GitHub Actions 的事件和市场生态让常见自动化容易启动，第三方 SaaS 也往往先提供 GitHub 集成。团队若采用云服务，可以把大量平台维护交出去。

代价是控制边界。代码、身份和流水线元数据依赖外部平台，数据驻留、网络可用性和合规要求可能成为硬约束。GitHub Enterprise Server 提供自托管路线，但运维与授权模型需要单独评估，不能把 github.com 的体验和价格直接套过去。

Actions 的便利还带来供应链风险。工作流能访问代码与密钥，第三方 Action 实际上是构建环境中的依赖；可写标签可能被移动，自托管 Runner 在执行不受信任代码后也可能留下持久化风险。官方安全指南建议固定到完整提交 SHA，并谨慎对待自托管 Runner。公开仓库尤其不能让来自 Fork 的任意代码轻易触碰生产凭据。

如果项目需要公开影响力、外部贡献与丰富集成，GitHub 是最自然的默认项。它的价值并非某个按钮独有，而是大量开发者、工具和文档已经围绕它形成共同语境。

Gitea：先把自己的代码安稳放下

Gitea 是 MIT 许可的开源自托管平台，强调轻量和易安装。仓库、代码审查、Issue、包注册表和兼容 GitHub Actions 思路的 Gitea Actions 已覆盖许多日常需求。个人、实验室、小团队或资源有限的内网环境，可以用较低成本拥有自己的代码服务。

轻量不仅指内存，也指心智。若需求只是账户、仓库、Pull Request、Webhook 和备份，Gitea 不会先要求部署一整套平台组件。数据和升级节奏掌握在自己手里，迁往另一台机器也较直接。

但「能用」与「治理深入」是两回事。大型企业需要的复杂审批、审计、合规报表、安全扫描、项目组合管理和庞大集成生态，GitLab 或 GitHub 往往更成熟。说得更直白一点：Gitea 在轻量自托管上很舒服，但作为完整研发平台偏弱。 它的能力边界意味着团队很快要自己补权限治理、审计、制品、安全和外围集成；这些补丁一多，最初的轻量优势就会被维护成本吃掉。Gitea 也提供企业产品，部分高级能力不能从社区版印象类推。Actions 与 GitHub Actions 相似，不表示所有 Marketplace Action、托管环境和细节都完全兼容，迁移时必须实际验证。

Gitea 最适合个人、小团队或只需要 Git 基础协作的内网；一旦团队需要跨项目治理、统一 CI/CD、安全扫描和可审计的发布链路，我不会因为它轻就坚持使用。它让团队获得所有权，也把备份、安全更新、邮件、Runner 隔离和灾难恢复交回团队。自托管不是「免费云服务」，只是账单从订阅费换成了机器与人的时间。

三、代码审查：看门禁怎样表达

Gerrit 把一次提交视为应被证明可以进入主线的变更。GitHub、GitLab 和 Gitea 更多围绕分支差异协作，一个 PR/MR 往往包含多个提交，最终可合并或压缩。前者让提交历史和逐次批准更精确，后者更贴近功能分支与产品迭代。

不要只数「需要两人批准」。还要明确代码所有者是否必须参与、作者能否批准自己、推送新提交后批准是否失效、管理员能否绕过、机器人失败能否覆盖、紧急修复如何留痕。规则越严格，越要提供可解释的错误和紧急通道，否则开发者会把治理视作随机路障。

四、CI/CD：方便启动，也要方便收拾

GitLab CI/CD 与平台数据结合最深，Merge Request、环境、制品和安全扫描可以连成一条链。GitHub Actions 胜在事件模型、托管 Runner 和 Marketplace 生态。Gitea Actions 让轻量自托管也拥有仓库内工作流，但兼容范围与 Runner 安全要逐项确认。Gerrit 通常把验证结果通过标签接回 Change，真正执行则交给外部 CI。

选择时至少核算以下成本：

• Runner 是共享、托管还是自建，峰值任务如何扩容；
• 缓存与制品存在哪里，保留期限和出口流量怎么算；
• 密钥如何分环境授权，来自外部贡献的代码能看到什么；
• 工作流依赖是否固定版本，谁负责供应链更新；
• 失败后能否定位到日志、追踪和具体基础设施；
• 平台故障时，能否仍然构建和发布紧急版本。

自托管 Runner 经常被误认为省钱按钮。它执行的恰恰是仓库里最有权限、最复杂的脚本。一旦让不可信变更落到长期存活且能访问内网的机器，攻击者可能窃取凭据或横向移动。更稳妥的做法是使用短生命周期、任务后销毁的隔离执行器，区分可信分支与外部贡献，并最小化网络和密钥权限。

CI 配置越依赖某个平台的专有表达，迁移越贵。但为了假想的未来迁移，把所有能力封装进自己维护的脚本，也会损失可视化、缓存和权限集成。合理做法是把核心构建与测试保留为可在本地执行的命令，让平台 YAML 负责编排和凭据，而不是把业务构建逻辑全写进条件表达式。

五、自托管的真正价格

把软件装起来只是自托管的第一天。第二天开始，团队要负责系统更新、数据库迁移、对象存储、证书、邮件、监控、日志、容量、漏洞修复和恢复演练。最危险的情况不是平台停一小时，而是备份一直显示成功，灾难时才发现附件、LFS 对象或加密密钥没有一起恢复。

GitLab 的能力最完整，相应资源和运维面也最大；Gitea 较轻，更适合规模有限的环境；Gerrit 常与其他工具组成系统，难点在集成与插件生命周期；GitHub SaaS 把基础设施交给供应商，却仍需治理组织权限、应用授权、账单、Runner 与数据导出。

如果决定自托管，至少要回答：

1. 恢复时间目标和恢复点目标是多少？
2. 备份是否包含数据库、Git/LFS、附件、包、配置和密钥？
3. 升级先在哪里演练，失败如何回滚？
4. 管理员账户与单点登录故障时有没有应急访问？
5. 谁接收安全公告，多久完成高危修复？
6. 平台负责人休假时，第二个人能否恢复服务？

如果这些问题没有答案，「代码在自己服务器上更安全」只是地理位置带来的心理安慰。控制权只有配上维护能力，才会变成安全。

六、迁移与避免被平台吞掉

平台迟早会涨价、调整功能、改变授权，团队也可能因并购、合规或网络条件迁移。无需因此拒绝所有平台能力，但应该保留出口。

Git 仓库要有可验证的异地镜像；Issue、审查、Release 和 Wiki 应定期导出；包和容器镜像要有清晰的保留策略；身份映射与机器人账户应文档化；构建入口保持本地可运行。对于关键仓库，可以定期在隔离环境做一次恢复，而不是只看备份文件大小。

迁移顺序也应按风险安排。先同步仓库并冻结短暂写入，再迁身份与权限，随后处理审查和 Issue，最后切 CI、制品、Webhook 与域名。旧平台保留只读窗口，避免为了追求「一次完成」而丢失讨论证据。不同平台的审查语义无法完全对应时，要接受有损转换，并把审计要求高的数据单独归档。

还有一种组合方案：Gerrit 负责强审查，GitHub 提供公开镜像；Gitea 放内部仓库，外部开源项目放 GitHub；GitLab 管交付流水线，同时从其他代码源拉取。组合能让工具各司其职，也会增加身份、同步和故障排查成本。只有边界清楚、收益具体时才值得，不要为了画架构图把四个平台集齐。

七、按场景给答案

公开开源项目：GitHub

外部贡献、发现能力、开发者账号覆盖和第三方集成是核心，GitHub 的网络效应最难替代。接受云平台依赖，并认真治理 Actions 权限、分支规则与恢复镜像。

严格提交审查：Gerrit

当每个提交都要独立批准，组织已有主线开发文化，并愿意维护专门审查系统时，Gerrit 的 Change、Patch Set 和 Submit Requirements 非常合适。它还有一个经常被忽略的前提：团队成员的工程习惯和 Git 基础要有比较统一的下限。 如果有人不理解 Patch Set、变基、提交粒度和标签门禁，Gerrit 的严格会先表现为沟通摩擦，再表现为绕过流程。若团队主要使用普通功能分支，不要只因「大公司在用」照搬仪式。

自托管一体化研发：GitLab

仓库、CI/CD、制品、安全和合规希望统一管理，且有平台团队承担升级与高可用时，GitLab 是稳妥选择。采购前按真实层级核对功能，不用未来也许需要的功能为当前复杂度背书。

个人、小团队与轻量内网：Gitea

只需要掌握数据、资源有限、协作流程常规时，Gitea 可以用；但如果这是一个多人长期协作的核心研发平台，我通常不会把它作为第一选择。它的产品面和治理能力相对弱，后续补齐外围系统的成本很容易超过一开始节省的机器资源。把省下的平台资源投入备份、更新和 Runner 隔离，别把「轻量」误解成「不用维护」。

已有平台：多数时候继续用

如果现有平台稳定、权限可控、团队熟悉，缺少某个新功能通常不足以支持迁移。先算迁移的机会成本和未来五年的运维成本。为了把按钮从蓝色换成橙色而搬迁十年审查记录，属于很有行动力地原地踏步。

八、我的选择原则

四个平台没有脱离场景的总冠军。它们优化的是不同约束：Gerrit 用学习与集成成本换审查纪律；GitLab 用平台重量换流程闭环；GitHub 用云依赖换生态与协作网络；Gitea 用较少高级能力换轻量和控制权。

我的默认选择会更偏向 GitLab 自托管：对多数需要私有代码、统一权限、CI/CD、制品和安全治理的团队，它在完整度与控制权之间最平衡。公开项目仍然放 GitHub；个人实验或极小型内网才考虑 Gitea；只有团队成员的 Git 和审查习惯足够统一、确实需要提交级强门禁时，才引入 Gerrit。Gitea 不是不能用，而是它太容易把「平台能力不足」伪装成「我们以后自己补」；多数团队最后补出来的是一套更难维护的半成品。

源代码托管的任务不是收藏代码，而是让变更安全、可追溯地进入产品。界面会改，套餐会变，热门工具也会轮换。先选择符合团队协作方式的平台，再保持仓库、构建和数据的出口。这样平台是一件工具，不是一份卖身契。