Gerrit 的评审模型
Gerrit 以 Change 为评审单位：每个提交带一个 Change-Id，修订时保持同一个 Change，评审人给出分值。它源自 Google 内部的评审实践，适合需要精细到提交粒度的流程，也让每一次修订都有独立的版本号可以追溯。
基本信息
| 评审单位 | Change，即一个提交及其多次修订 |
|---|---|
| 投票 | 评审分 -2 到 +2，验证分 -1 到 +1 |
| Change-Id | 写在提交信息尾部，修订时保持不变 |
| 来源 | Google 内部的评审实践 |
典型使用场景
- 大仓库多团队协作：按提交粒度评审，减少互相等待
- 需要严格的合并前验证：验证分由流水线投票给出
- 追溯每次修订：Change 保留完整的版本历史
- 维护者审核制度：合并权限与评分权限分开配置
- 与提交信息规范结合：Change-Id 与提交说明一并检查
评分语义速查
- 评审 +2：可以合并，通常需要维护者给出
- 评审 +1：认可，但不足以放行
- 评审 -1：有意见，需要修改后再看
- 评审 -2：硬阻挡，必须说明理由并推动解决
- 验证 +1：流水线的构建与测试通过
提交流程
提交流程
git commit -s # 提交信息尾部带 Change-Id
# Change-Id 由仓库里的 commit-msg 钩子生成
git push origin HEAD:refs/for/main # 推到评审分支，而不是直接推主干与平台式评审的差别
| 维度 | Gerrit | 平台式评审 |
|---|---|---|
| 评审单位 | 提交及其补丁集 | 分支上的整个改动 |
| 修订方式 | 追加新的补丁集 | 向分支追加提交 |
| 放行条件 | 评分达到阈值并通过验证 | 批准加上流水线通过 |
在评审中怎么用
- 先看补丁集的差异，确认上一轮意见已经闭环
- 评分要附理由，硬阻挡尤其需要说明解决路径
- 修订保留同一个 Change-Id，讨论不丢上下文
- 合并前确认验证分来自流水线而不是人工给出
修订时保留同一个 Change-Id：否则同一个问题的多次修订会被拆成互不相关的多个 Change。
Change 的历史本身就是评审记录：每次修订对应的讨论都留在同一个页面上，回溯成本很低。
用 +1 表示批准：在 Gerrit 的语义里 +1 并不构成可合并条件。