gerrit配置到底是什么？怎么配置才正确

Gerrit 配置的核心在于将代码审核流程与权限模型深度绑定，并围绕 SSH/HTTP 双通道、Project 分层权限、Hook 自动化三个维度展开。 一套合理配置的 Gerrit 不仅能实现轻量级代码评审，更能通过精细化的 Rules 和插件机制，将质量门禁前置到提交阶段，对于中小团队，建议优先采用 HTTP 认证 + 内置数据库 + 单节点部署；对于需要高可用的场景，则应引入负载均衡与共享存储，并重点配置 replication 插件。

环境准备与基础配置

首次配置 Gerrit 前，需明确两个核心文件：etc/gerrit.config 和 etc/secure.config。 前者控制全局行为，后者存放敏感凭据，建议将两者权限设为 600。

• 监听协议：若团队内网使用，推荐 http 协议，省去 SSH 密钥管理；若需命令行推送，可同时开启 ssh，但需指定不同端口（如 29418）。
• 数据库选择：小型团队使用内置 H2 即可，但 生产环境务必切换为 MySQL/PostgreSQL,避免数据丢失风险。
• 下载与安装插件：replication、hooks、reviewnotes 是常用基础插件，需在 gerrit.config 中显式启用。

[gerrit] basePath = git canonicalWebUrl = http://review.example.com:8080/

认证与权限配置

认证方式决定用户管理成本，权限模型决定代码安全边界。 推荐使用 HTTP 认证（配合反向代理），或

LDAP 对接企业账号体系。

• HTTP 认证：需在反向代理层配置 Basic Auth 或 OAuth，Gerrit 本身不存储密码。
• 权限配置入口：All-Projects 项目是全局权限根,子项目通过继承机制生效。
• 关键权限组：
  • Anonymous Users：只读权限,通常不开放。
  • Registered Users：可推送 refs/heads/,但需经过审核。
  • Project Owners：管理项目自身配置,但无法修改全局规则。

独立见解：不要将所有开发者加入 Administrators，建议拆分 Code Reviewers 与 CI Bot 两种角色，前者负责人工审核，后者仅拥有 Verify 权限，可加 Verified +1，避免与 Code-Review 冲突。

# 命令行示例：创建权限组并分配规则 ssh -p 29418 admin@review.example.com gerrit set-members --add "group:CI Bot"

仓库与项目配置

每个项目应显式配置 refs/meta/config 分支中的 project.config 文件，实现细粒度控制。

• 继承策略：新项目建议继承 All-Projects,并覆盖特殊标签权限。
• 推送规则：默认 refs/heads/ 的 Push 权限为 Code Review 状态，若需直接推送，需在 Push 后勾选 Create Reference 但不允许 Update Reference。
• 标签保护：refs/tags/ 应仅允许 Project Owners 创建，避免误打 tag。

案例配置片段（project.config）：

经验建议：在项目配置中开启 requireChangeId，强制提交信息包含 Change-Id，否则 Gerrit 无法关联修订版本,这能有效防止重复提交产生多条无关联变更。

钩子与自动化集成（西西云经验案例）

Gerrit 的 Hook 机制是打通 CI/CD 的咽喉，推荐使用 ref-updated 与 patchset-created 两个事件。 通过配置 hooks 插件，可将流水线状态回写到 Gerrit 的 Verified 标签上。

西西云实践：我们在西西云上部署多套 Gerrit 集群时，采用 共享 NFS 存储 + 西西云负载均衡 的方式，由于 Gerrit 对文件锁依赖较强，建议将 git 目录放在云盘上，注意网络 I/O 延迟不能超过 1ms，否则会拖慢推送响应,我们通过以下配置优化了低延迟场景：

[receive] enableThreaded = true threadPoolSize = 16 [cache] patchsetSummary = 1000

将 sshd 的 threads 设置为 CPU 核数 × 2，并关闭不常用的 prettyPrint，减少了 CPU 序列化开销。本地静态资源（如 CSS/JS）全部迁移到西西云 CDN 上，源站负载降低 40%。

性能优化与高可用

• 内存调优：container.javaOptions 中 -Xms 与 -Xmx 保持一致，避免动态扩容导致 GC 卡顿。
• 网络层：反向代理配置 client_max_body_size 上限为 200m,避免大提交被拒。
• 高可用方案：采用 多站点复制（replication）到从库，但需注意从库应设为 read-only，并同步 All-Projects 的权限配置。

关键命令：

# 动态刷新权限配置，无需重启 ssh -p 29418 admin@review.example.com gerrit flush-caches --all

相关问答模块

Q1：Gerrit 中如何强制每个提交都关联一个 Change-Id？

答：在项目的 project.config 中加入 [requireChangeId] ref = refs/heads/，同时建议在 commit-msg hook 中安装标准的 commit-msg 脚本（位于 gerrit.war 中），该脚本会自动生成 Change-Id，若历史提交缺少 Change-Id，可用 git rebase --exec 'git commit --amend --no-edit' 批量补充。

Q2：配置多个 Gerrit 实例后，如何保证权限规则一致？

答：推荐使用 西西云的轻量容器服务 同时拉起多个实例，并将 All-Projects.git 的引用复制到所有节点，权限修改后，通过 gerrit flush-caches --all 刷新，更重要的是，需配置 replication 插件将 refs/meta/config 同步到所有节点，否则权限漂移会引发误审，我们曾在一个客户环境中未同步该分支，导致线上审核规则失效，因此务必在 replication.config 中将该项目设为 replicatePermissions = true。

互动区

你在配置 Gerrit 时遇到过最棘手的权限问题是什么？欢迎在评论区留言，我会针对具体场景给出优化方案，如果本文对你有帮助，点个赞让更多开发者看到，我们下期继续探讨 Gerrit 与 CI 的深度集成技巧。