Gerrit配置的核心是双轨并行：先用gerrit.config和权限文件把服务骨架搭好，再用SSH命令行管理仓库与用户，任何一步遗漏都会导致代码审核流程卡壳。
gerrit配置管理的核心入口：配置文件与命令行
接触过Gerrit的人都知道，它的配置不像普通Git服务改个config就完事，Gerrit把配置拆成了两层：一层管服务本身，另一层管每个项目的权限，刚开始接触时，我把所有配置都堆在gerrit.config里，结果项目一多权限就乱套，还闹过同事误推refs/heads绕过评审的笑话，后来才悟出规律：服务配置走文件，项目配置走仓库,缺一不可。
第一次配置gerrit要搞清的几件事
配置文件：Gerrit安装目录下的etc/gerrit.config是主心骨，里面定义了数据库、HTTP端口、SSH端口和认证方式，默认的认证方式在初始化向导时会让你选，国内团队用得比较多的是HTTP加LDAP，或者纯HTTP密码认证（用本地账户库）。
项目权限：Gerrit的每个项目都自带一个refs/meta/config分支，这个分支里放着project.config文件，你要让谁能发起评审、谁能打Verified+1、谁能直接推refs/heads,全在权限条目里列明。
reviewdb数据库：配置里指向的reviewdb建议单独建库，别跟应用库混在一起，我见过一台测试机上Gerrit和业务系统共用MySQL，结果业务表被误清空，Gerrit的账户表也跟着遭殃，恢复起来相当花时间，據业界常用的部署实践,数据库独立之后备份和迁移都省心不少。
gerrit配置多个SSH Key的正确姿势
团队里一个人用多台设备很常见，办公电脑、家用笔记本、甚至服务器跳板机，每台机器都生成一对密钥,然后把公钥都添加到Gerrit账户里就行。
具体操作路径是：登录Gerrit网页端，点击右上角头像，进入Settings → SSH Keys，把每台机器的id_rsa.pub内容粘进去。贴公钥时注意格式，ssh-rsa开头、user@host结尾的完整内容要一次贴全，缺头少尾Gerrit会直接报invalid key。
有同事问过：gerrit配置多个SSH Key会不会影响权限识别？答案是不会，Gerrit按密钥找账户，同一个账户下多个密钥权限完全一致，不过要注意
别拿同一个公钥去注册两个Gerrit账户，那样会导致推代码时认证歧义,服务端会拒掉你的请求。
gerrit配置与jenkins联动：CI场景下的关键参数
Gerrit最常见的搭档就是Jenkins，代码推上来，Jenkins自动跑构建，再把结果以Verified标签回写到Gerrit，联动配置不对，最典型的现象是代码一直卡在审核队列里，Jenkins也报了构建成功，但Gerrit界面上就是看不到任何验证结果。
三步完成gerrit配置与jenkins的钩子设置
- 安装插件：在Gerrit的
plugins目录下放好events-log插件（新版是webhooks），开启后重启Gerrit服务,让事件能往外推。 - Jenkins侧装插件：给Jenkins安装
Gerrit Trigger插件，在系统设置里填Gerrit的SSH地址、端口（默认29418），并导入Gerrit的SSH公钥，公钥内容从Gerrit服务器上的~/.ssh/id_rsa.pub里拿。 - 配置触发规则：在Gerrit Trigger的
Gerrit Project里填项目名（如my-app），勾选Gerrit event里的Patchset Created和Comment Added两个事件，这样新补丁集上来或者有人打评论时,构建才会被触发。
联动时的权限注意事项
Jenkins要回写验证标签，光有触发不够，还得有权限，在project.config里要给Non-Interactive Users组加上Label Verified的权限，取值范围通常设-1..+1。
行业共识认为，验证标签权限别给到开发组，开发自己标记自己代码为Verified会绕过人工审核，评审流程就形同虚设，Jenkins的构建用户单独建一个，只给它触发和打标签的权利,读写代码的分支权限关掉。
场景型配置：大数据量仓库与多团队协作
随着仓库膨胀，Gerrit配置也要跟着调整，一个大型Android项目如果按默认配置跑，内存占用会持续走高，最终表现为网页响应迟缓、SSH连接超时。
大数据量仓库怎么调
- 增大接收限制：
receive.maxBatchCommits默认是10000，如果团队喜欢一次性推送大批量提交，要适当调大，但调太大也会带来内存压力,建议按团队实际最大提交量来定。 - 启用
changeCache：打开网页端Settings→Performance，确认Change Cache相关选项是开启状态,这个缓存能有效降低浏览评审列表时的数据库压力。 - JVM参数调整：统计显示，Gerrit实例在大型仓库下，堆内存分配不足是OOM的头号原因，在
$GERRIT_SITE/bin/gerrit.sh里把-Xmx参数从默认的1g提到4g,同时注意服务器物理内存要有冗余。
gerrit配置后无法推送代码？一般按这个顺序排查
推送时报remote rejected是最常见的问题,我建议你按下面这个顺序排查：
- Change-Id是否缺失：查看本地提交信息末尾有没有
Change-Id: Ixxxxxx，没有就说明commit-msg钩子没装，去Gerrit服务器上执行scp -p -P 29418 用户名@主机名:hooks/commit-msg .git/hooks/获取。 - 目标分支权限：确认要推的
refs/for/master里的master分支是否确实存在，且当前用户有该分支的Push Merge或Push权限。 - SSH密钥认证：本地执行
ssh -p 29418 用户名@主机名，看是否返回welcome信息，有的话说明SSH通,没有则检查密钥添加和主机别名配置。 - 事件日志核查：网页端到
Administration→Logs里翻SSH访问日志，能看到具体的拒绝原因,比盲猜快得多。
评审状态与权限维护的细节
配置工作做完后，日常维护一样重要，Gerrit的评审状态有New、In Review、Verified、Submitted等几个层次，每个状态对应哪些人能操作,权限表里要有明确约束。
多分支保护的正确配置
不少团队在refs/heads/上统一设了禁止直接推送，只在个别发布分支（如release/）放开给特定管理员。
refs/heads/：全员Push权限取消，开发人员依赖refs/for/推代码进行评审。refs/heads/release/：只给Release Manager组的成员开Push和Submit权限。- 权限条目越靠前优先级越高，特殊分支规则放在`refs/heads/`前面,否则会被通配规则覆盖。
小团队gerrit配置的取舍逻辑
小团队（5人以下）没必要把权限模型搞得太复杂，维护成本方面，越精细的权限矩阵意味着越多的group和rule需要维护，出问题的概率也越高，有相当一部分初创团队直接使用默认的Anonymous Users和Registered Users分组，把开发人员全归到一个组里，用Label Code-Review和Label Verified来把控质量，反而简单直接、不容易出错。
关于gerrit配置的三个高频疑问与解答
gerrit配置改动后必须重启服务才能生效吗？
分情况。权限相关配置（project.config）不需要重启，推送到refs/meta/config分支后立即生效。服务级配置（gerrit.config里的网络、数据库、端口部分）需要重启才能生效，改动之前先敲ssh -p 29418 用户@主机名 gerrit version确认SSH通道能通，再执行$GERRIT_SITE/bin/gerrit.sh restart，重启过程通常持续几十秒,期间网页和推送都会短暂中断。
gerrit配置管理里能不能直接用HTTPS代替SSH？
能，但两者适用场景不同，HTTPS对防火墙更友好，国内团队如果自建服务且网络环境限制了SSH端口，用HTTP认证加密码方式更便捷，不过HTTPS方式下每个开发都要记住账户密码，容易出现密码泄露风险，SSH方式密钥即身份，管理起来方便很多，也便于撤销单个设备权限，Gerrit官方文档里推荐生产环境使用SSH，本地小规模试用可以选择HTTP。
gerrit配置与Gitlab配置的管理逻辑有什么不同？
核心差异在评审机制，GitLab的Merge Request是分支级别的请求，权限模型偏仓库维度；Gerrit的Change则是提交级别的评审，权限细化到refs/for/，每个补丁集都能独立验证，用过两者切换的团队普遍的感受是：GitLab配置上手快，但跨分支跟踪能力弱；Gerrit配置前期学习成本高，一旦跑顺，分支保护和原子提交的严谨性是GitLab短时间内追不上的，这也是许多嵌入式与Android项目宁可多花人力也要维护Gerrit的原因严格受控的评审意味着安全上的确定性。
配置只是开始，真正有价值的是一套团队认可的评审规范，工具简化了流程，但人得优先理解为什么要有这些限制，讨论多了,Gerrit用起来才会顺手。