Gerrit代码审查从入门到真香

Gerrit 代码审查从这啥玩意儿到真香最近团队里有人提议“咱们上 Gerrit 吧。” 我第一反应是“GitLab 不是用得好好的吗又整啥新花样” 结果用了两个月之后我只想说两个字——真香。一、问题来了代码 review 怎么总是流于形式先说说咱们大多数人熟悉的代码审查流程本地写代码git push到远程分支提个 Merge Request / Pull Request同事点进去看看评论几句改完再 push合并进主分支这流程本身没问题但实际操作中你懂的——很多 MR 就是走个过场。要么 review 的人草草扫两眼就点了 “LGTM”Looks Good To Me要么等发现问题的时候代码早就合进去了只能再补一个 “修复 XX 问题” 的提交。更头疼的是有些团队为了 “规范”要求每个人必须 review 通过才能合并。结果开发者为了省事直接 push 到主分支或者找个人 “秒过”审查制度形同虚设。说白了我们需要一个机制让代码审查真正成为合并前的 “硬门槛”而不是一个可跳过的 checkbox。这时候Gerrit 登场了。二、Gerrit 到底是啥跟 GitLab 有啥不一样Gerrit 是 Google 开源的一款基于 Git 的代码审查工具。它长得像个代码托管平台但核心定位只有一个代码审查。它和 GitLab/GitHub 最大的区别特性GitLab/GitHubGerrit代码托管✅ 完整支持⚠️ 基础支持偏 review 导向CI/CD✅ 内置❌ 需配合 Jenkins 等Issue 管理✅ 内置❌ 没有代码审查粒度文件级评论行级精准评论合并前审查可选可绕过强制无法绕过提交历史可能很乱fix-1, fix-2…通过 ammend 保持整洁Gerrit 的设计理念很 “硬核”没有 review 通过的代码绝不允许进入代码库。三、Gerrit 的核心概念Change、Patch Set、Label刚接触 Gerrit 的时候界面和术语确实让人有点懵。别急咱们用三分钟搞清楚三个核心概念。1. Change变更你的一次代码提交在 Gerrit 里叫做一个Change。每个 Change 有一个唯一的 Change-Id类似于 “这次改动的身份证”。2. Patch Set补丁集你根据 review 意见修改后再次提交不会生成新的 Change而是生成一个新的Patch Set。也就是说一个 Change 可以包含多个 Patch Set记录了你 “改了多少版”。# 第一次提交 → Gerrit 上生成 Change #1234Patch Set 1# 根据意见修改后再次 push → Change #1234Patch Set 2# 再改一次 → Change #1234Patch Set 3这有什么好处整个 review 过程都在一个 Change 里完成提交历史不会被一堆 “fix review comments” 的 commit 污染。3. Label评分标签Review 的人不是简单地点个 “通过”而是要打分。最常见的两个 LabelCode-Review代码质量评分通常是2通过、1看起来还行但没把握、-1有问题、-2否决不能合VerifiedCI 构建/测试结果通常是1通过、-1失败只有当所有必需的 Label 都达到指定分数时这个 Change 才能被合并。这就把代码审查从 “软约束” 变成了 “硬规则”。四、上手实战从第一次 push 到合并好了概念讲完咱们来走一遍实际流程。第一步配置本地 GitGerrit 不用普通的git push origin feature-branch而是通过一个特殊的refs/for/目标分支来提交代码。# 配置 push 到 Gerrit 的快捷方式gitremoteaddgerrit ssh://yournamegerrit.example.com:29418/your-project.git# 安装 commit-msg hook自动生成 Change-Idscp-p-P29418yournamegerrit.example.com:hooks/commit-msg .git/hooks/注意这个commit-msghook 很关键没有它Gerrit 就认不出你的 Change每次 push 都会生成一个新的 Changereview 记录全丢了。第二步提交代码# 正常写代码、提交gitadd.gitcommit-mfeat: 新增库存校验逻辑# push 到 Gerrit 进行 reviewgitpush gerrit HEAD:refs/for/main如果一切正常你会看到类似这样的输出remote: Processing changes: new: 1, done remote: remote: New Changes: remote: https://gerrit.example.com/c/your-project//1234 feat: 新增库存校验逻辑第三步根据 review 意见修改同事在 Gerrit 上给你提了几条 comment你改完之后不要新建 commit而是 amend 当前 commit# 修改代码...gitadd.gitcommit--amend--no-edit# 保持 commit message 不变保留 Change-Id# 再次 pushgitpush gerrit HEAD:refs/for/main这时候 Gerrit 上 Change #1234 就会新增一个 Patch Set 2之前的 review 评论和打分记录都还在同事可以方便地看到 “你改了哪些地方”。第四步通过审查合并代码当 Change 拿到足够的Code-Review 2和Verified 1后你就可以点击Submit按钮合并了。合并后的提交历史干干净净只有一个 commitfeat: 新增库存校验逻辑而不是feat: 新增库存校验逻辑 fix: 修复 review 意见 1 fix: 再修一个小问题 fix: 修 CI 报错五、Gerrit 的一些 “坑” 和注意事项用了这段时间我也踩过几个坑分享出来帮你避避雷。坑 1Change-Id 冲突如果你 cherry-pick 了一个已经存在于 Gerrit 的 commit 到另一个分支Change-Id 是一样的Gerrit 会认为这是同一个 Change 的不同分支版本。如果你不想这样需要手动删掉 commit message 里的 Change-Id让 hook 重新生成一个。坑 2git commit --amend用不习惯很多同学习惯了 “改一点就 commit 一点”到了 Gerrit 这里要忍住。一个 Change 对应一个 commit所有修改都通过 amend 和 force pushGerrit 允许针对 refs/for/* 的 force push来完成。刚开始会觉得别扭但习惯了之后你会发现提交历史真的清爽很多。坑 3权限配置比较复杂Gerrit 的权限系统非常细粒度可以精确控制谁能 review、谁能 submit、谁能 bypass review。但这也意味着初次配置的时候比较烧脑建议参考官方文档或者找个配过的同事带一带。六、什么场景适合用 Gerrit说了这么多Gerrit 并不是银弹。根据我的观察下面这几类团队特别适合对代码质量要求高的团队比如基础架构组、核心中台组代码审查必须严格执行。需要保持干净提交历史的项目Gerrit 天然鼓励使用git commit --amend历史非常整洁。已经有独立 CI/CD 工具链的团队Gerrit 本身不做 CI/CD配合 Jenkins、GitHub Actions 等使用很合适。习惯 “先 review 后合并” 工作流的团队如果你本来就认同这个理念Gerrit 会让流程更顺畅。反之如果你是个小团队追求 “一站式” 平台代码托管 CI/CD 项目管理GitLab 可能更省心。七、总结Gerrit 给我的最大感受是它把代码审查从 “建议” 变成了 “规则”从 “事后检查” 变成了 “事前把关”。当然工具只是辅助最终代码质量还是取决于 review 的人是否认真。但至少Gerrit 提供了一个不容易被绕过的机制让 “认真 review” 成为可能。如果你也正在为团队的代码审查流于形式而头疼不妨试试 Gerrit。刚开始可能会有点不适应但用上一段时间你可能也会跟我一样——真香。你们团队是怎么做代码审查的用过 Gerrit 吗体验如何欢迎在评论区交流