Gerrit 介绍与选型指南

目标：说清 Gerrit Code Review 的定位、Change 评审模型与核心架构，并与 GitLab、Gitea、Phabricator 做量化选型对比，帮助团队判断「是否需要 Gerrit、什么时候选 Gerrit」。本篇为认知篇，全部信息均联网溯源自官方渠道（官网、官方文档站、官方 Release Notes、shields.io 徽章数据），未做本地实测。

一、环境信息

本篇为介绍与选型认知篇，仅联网溯源，不涉及本地部署。信息来源与取证口径如下：

• 软件：Gerrit Code Review（官方站点 gerritcodereview.com，代码评审主实例 gerrit-review.googlesource.com）
• 最新稳定版本：3.14.4（官网首页 Download 按钮 2026-10-27 实查，下载件 gerrit-3.14.4.war）
• 开发中版本：3.15（官方 Releases 页标注 in development，引入 Java 25）
• 开源许可：Apache License 2.0
• 技术栈：Java（内嵌 Jetty + JGit，前端 PolyGerrit 基于 Lit 框架）
• 代码仓库：主开发托管在 Gerrit 自己的评审实例上（gerrit-review.googlesource.com）；GitHub 镜像 GerritCodeReview/gerrit
• 社区热度：GitHub 镜像 1.2k stars / 280 forks（shields.io 徽章 2026-10-27 取证；Gerrit 主开发不走 GitHub，该数字不代表其真实用户规模，Android/Chromium 等巨型项目均在其自托管实例上评审）
• 信息查询日期：2026-10-27（版本号、特性清单、星数等均以该日期为准）

二、软件概述

Gerrit 是一个基于 Web 的代码评审与 Git 托管平台，官方对其一句话定位是「The open source, patchset based, code review platform for Git-based development」——面向 Git 研发的开源、以补丁集（patchset）为评审单元的代码评审平台。它由 Google 在 2011 年前后从 Android 开源项目的工程实践中孵化开源，至今仍是 Android、Chromium 这类万级开发者巨型仓库的标准评审基础设施。

Gerrit 与 GitLab、Gitea 最根本的差异在于评审模型：GitLab/Gitea 采用「分支 + Pull Request/Merge Request」模型，而 Gerrit 采用「Change（变更）模型」——每一次 git push 推送到魔术引用 refs/for/<目标分支>，产出的不是一个待合并的分支，而是一个独立的、可逐版迭代的评审单元。同一逻辑修改推第二次会生成同一 Change 的第二个 patchset（补丁集），评审意见逐 patchset 沉淀、追溯。

💡 技术拓展：代码评审工作流不止 Gerrit 一种模型。业界主流三种模型对比——

模型	代表平台	工作方式	适用场景
Change-based（变更模型）	Gerrit、Phabricator Differential	每次提交即一个独立评审单元，推送到 refs/for/分支 魔术引用，逐 patchset 迭代打分	强门禁治理、巨仓、内核式工作流
PR/MR-based（拉取请求模型）	GitHub、GitLab、Gitea	功能分支整体发起请求，按分支合并，评审对象是分支差异	通用团队协作、敏捷迭代
Mailing-list patch-based（邮件补丁模型）	Linux 内核（git send-email）	补丁以邮件形式发送、逐条回复评审	超大规模开源社区、强邮件文化

Gerrit 的 Change 模型在理念上最接近邮件补丁模型（官网原话：「more closely resembles the proven mailing list workflow used by Git itself and the Linux kernel」），但把流程固化成了平台内的结构化评审单元。本文主角 Gerrit 即 Change-based 模型的代表实现。

版本演进方面，Gerrit 保持每半年一个大版本（minor）的节奏，patch 版本持续滚动发布。近几个大版本的关键演进（官方 Releases 页 2026-10-27 实查）：

三、核心架构

Gerrit 是单进程 Java 服务，架构围绕「以 Git 为唯一事实源」设计，组件分工如下：

3.1 数据层：JGit 与 NoteDb

Gerrit 没有自己的对象存储，仓库就是标准 Git 裸仓库，Git 协议层用纯 Java 实现的 JGit（Eclipse 基金会项目，Gerrit 同源团队维护）。3.0 起所有评审元数据（Change 状态、评审意见、打分、审批轨迹）全部落在 NoteDb——即以 Git 分支内嵌 note 的形式存储在每个仓库的 refs/changes/.../meta 引用下，评审历史与代码历史同库同源，天然可审计、可复制。

3.2 服务层：HTTP 与 SSH 双协议

• HTTP daemon（默认 8080 端口）：承载 PolyGerrit Web UI 与 REST API；
• SSH daemon（默认 29418 端口）：承载 SSH 命令行管理面（gerrit ls-projects、gerrit query 等全套命令）与 Git SSH 协议推拉。

两个端口都是评审流程的基础设施：开发者日常 git push 走 SSH（29418），浏览器评审走 HTTP（8080）。

3.3 索引与数据库

• 二级索引：默认内嵌 Lucene，可切换 Elasticsearch / OpenSearch（大规模站点选型项）；
• 元数据库：H2（内嵌默认）、PostgreSQL、MariaDB/MySQL 三选一。NoteDb 承担了评审元数据后，关系库仅存账户、群组等少量实体，体量与备份压力远小于传统 forge。

3.4 插件与扩展

Gerrit 的可扩展性由三层机制构成：进程内 插件（plugin） 体系（官方维护 replication、webhooks、delete-project、gitiles 等，社区生态 100+ 插件）、REST API 全覆盖（评审、项目、账户、群组全资源可编程）、SSH 命令行 管理面。典型扩展链路：replication 插件把已合入提交实时镜像到 GitHub/备份仓库；multi-site 插件实现多站点双活。

3.5 认证体系

支持 OPENID、LDAP、HTTP_LDAP、OAUTH、GITHUB 等多种认证后端，企业环境最常见的组合是 LDAP（对接公司目录）或 HTTP 反向代理层认证。3.13 起 HTTP 密码机制开始废弃、转向 token 化，API 凭据管理向现代做法收敛。

四、功能特性

以下特性均溯源自官网功能页与 Release Notes（2026-10-27）：

1. Change/patchset 评审模型：每次推送到 refs/for/<分支> 生成 Change，修改重推自动生成下一版 patchset；评审意见逐版本留存，diff against previous patchset 逐版对比。
2. 标签打分与提交门禁：内置 Code-Review（-2/-1/0/+1/+2）与 Verified 标签，3.6 起用声明式 Submit Requirements（取代 Prolog 规则）定义合入条件，如「Code-Review 必须有两个 +2 且 +2 者非提交者」。
3. 依赖链（Related Changes）：多个互相依赖的 Change 组成 DAG，评审界面直接可见依赖图，自底向上逐个合入，也支持整链 rebase/cherry-pick。
4. 细粒度权限：权限按「项目 → 分支引用 → 操作」三级定义（如仅 refs/heads/release/* 允许 submit），颗粒度显著细于常见 forge 的分支保护。
5. Attention Set 与协作效率：自动聚焦「当前该谁行动」（评审人/作者），未解决评论跨 patchset 迁移、Suggested Fixes 一键采纳修复建议。
6. 3.14 新特性：WebUI 现代化改造、Review Agent（AI 对话评审）、Gerrit Flows、粘性表头与性能优化。
7. CI/CD 集成：Jenkins（Gerrit Trigger 插件，逐 patchset 触发验证打 Verified 分）、Zuul 门禁系统、GitHub Actions（github 插件）、webhooks 通用对接。
8. 企业级扩展：replication 镜像复制、multi-site 多站点双活（active-active）、零停机升级（官网企业扩展性页宣称支持数千并发开发者与超大仓库的全局复制）。
9. REST API 与自动化：全资源 REST API + SSH 命令行 + stream-events 事件流，评审流水线可完全程序化。

五、快速开始（最小可用示例）

本节命令引自官网首页 Getting Started 的 Standalone 路径（官方推荐的最快上手方式，2026-10-27 实查原文），用于建立整体认知；生产级部署（含持久化、认证、反代）见本专栏部署篇。前置要求：已安装 Java 21 及以上运行环境（3.12 起不再支持 Java 17）。

# 1. 下载官方 war 包（单文件发行，内嵌 Jetty）
wget -O gerrit.war https://gerrit-releases.storage.googleapis.com/gerrit-3.14.4.war

# 2. 初始化站点目录：--batch 免交互向导，--dev 开发者快速模式，--install-all-plugins 安装全部官方插件
java -jar gerrit.war init -d /path/to/gerrit/site_dir --dev --batch --install-all-plugins

# 3. 启动服务
cd /path/to/gerrit/site_dir && bin/gerrit.sh start

启动后默认监听 HTTP 8080（Web UI 与 REST API）、SSH 29418（Git 推拉与管理命令），浏览器访问 http://<服务器>:8080 即进入 PolyGerrit 界面。init 过程会生成站点目录 etc/gerrit.config 主配置与 etc/secure.config 密钥配置——这两份配置文件逐节详解见本专栏配置篇。

官网同时提供 GerritHub.io 免费托管（可对接 GitHub 仓库自动镜像复制）作为零部署的体验路径，以及 Kubernetes 侧的 gerrit-operator 社区生态（第三方运维路径，本批部署篇附节溯源介绍）。

六、适用场景与限制

6.1 适用场景

1. 强评审门禁组织：合入必须满足「Code-Review +2 且非本人 + Verified 通过」，门禁是平台强制的结构化流程而非分支保护可绕过的建议项——金融、合规、车载、基础软件团队的核心诉求。
2. 超大仓库与超大团队：Android、Chromium、Qt、OpenInfra 基金会（OpenStack，review.opendev.org）等万级开发者项目长期生产验证，multi-site 支持多站点双活。
3. 内核式主线开发：子模块众多、提交间存在依赖链、要求「每个提交独立可评审、可追溯、可单独 revert」的研发模式。
4. 开源社区主线治理：开源项目方希望对主线仓库保持合入裁决权，同时接受外部贡献者提交（贡献者无需仓库写权限，push 到 refs/for/ 即可发起评审）。

6.2 限制与成本

1. 学习曲线陡峭：refs/for/ 魔术分支、Change/patchset 概念、commit-msg 钩子（Change-Id 注入）对从 PR 模型迁移来的团队是真实的心智负担，需要一周左右的团队培训期。
2. 无内置 Issue 跟踪：Gerrit 只做评审与托管，缺陷/需求管理需外挂 Jira、GitHub Issues 或 Redmine 等独立项目管理系统（评审通过与 Issue 状态联动可用 REST API 桥接）。
3. 无内置 CI：需自行集成 Jenkins（Gerrit Trigger）、Zuul 或 GitHub Actions 插件，初始搭建工作量高于 GitLab 开箱即用的 CI/CD。
4. 社区规模相对小众：GitHub 镜像星数 1.2k，中文社区资料少于 GitLab/Gitea，排障更多依赖官方文档站与邮件列表。
5. UI 个性化有限：PolyGerrit 界面重评审效率、轻视觉定制，与 GitHub 式现代交互有差距（3.14 正在现代化改造，但整体风格仍偏工程向）。

七、同类选型对比

7.1 量化对比总表

对比对象：Gerrit 3.14.4、GitLab CE（当前 18.x 系列）、Gitea（当前 1.24 系列）、Phabricator（终止版本 2021.24 + 社区延续项目 Phorge）。星数与版本信息取证渠道：shields.io 徽章与各官方发布页，查询日期 2026-10-27。

关键差异解读：Gerrit 与 GitLab/Gitea 不是同一赛道的直接竞品——GitLab/Gitea 的强项是「研发全流程一站式」（托管+评审+CI+Issue），Gerrit 的强项是「把代码评审做到极致的门禁基础设施」。评审对象差异是本质差异：Gerrit 评审的是「提交序列（patchset）」，PR 模型评审的是「分支差异」；前者天然适配「一个特性拆 10 个依赖提交、逐个评审逐个合入」的重工程流程，后者更适合「一个特性一个分支整体合入」的敏捷流程。

7.2 选型建议

按「如果……则……」给出直接结论：

• 如果合入必须双人评审门禁、需要逐提交评审与依赖链管理 → Gerrit；
• 如果要一站式 DevOps（评审 + CI/CD + Issue + 包管理）且团队习惯 PR 模型 → GitLab CE；
• 如果追求轻量 Git 托管与低资源占用、团队小且流程灵活 → Gitea；
• 如果是 Phabricator 存量用户 → 官方已停更，评估社区延续的 Phorge 或直接迁移到 Gerrit（Gerrit 3.7+ 提供从其他服务器导入项目与 Change 的能力）；
• 如果是 Linux 内核级超大型开源社区、贡献者不拥有仓库写权限 → Gerrit（refs/for 工作流正是为此设计）。

八、参考链接

1. Gerrit 官网：https://www.gerritcodereview.com/
2. 官方文档站：https://gerrit-review.googlesource.com/Documentation/
3. 版本发布总览（Release Notes 汇总）：https://www.gerritcodereview.com/releases/README.md
4. 官方下载站（war 包）：https://gerrit-releases.storage.googleapis.com/index.html
5. GitHub 镜像仓库：https://github.com/GerritCodeReview/gerrit
6. 官方容器发行页（Docker Hub）：https://hub.docker.com/r/gerritcodereview/gerrit
7. 插件生态页：https://www.gerritcodereview.com/plugins.html
8. GerritHub.io（免费托管体验）：https://gerrithub.io/
9. 企业支持与版本支持状态：https://www.gerritcodereview.com/support.html
10. REST API 文档：https://gerrit-review.googlesource.com/Documentation/rest-api.html