Gerrit的使用教程

在 Gerrit 中进行代码分支管理，核心是结合 Git 的分支模型与 Gerrit 的代码审查流程，通过权限控制和审核机制确保分支的稳定性。Gerrit 本身不直接管理分支（分支本质由 Git 维护），但通过配置规则（如 “必须审核才能合并”“禁止直接推送”）规范分支操作。以下是具体实践方法：

一、选择合适的分支策略（与 Git 一致）

Gerrit 兼容常见的 Git 分支模型，需先根据团队需求选择合适的策略，再通过 Gerrit 强化流程：

1. Trunk-Based Development（主干开发）

   • 核心分支：main（或 master）作为唯一长期分支。
   • 短期分支：仅创建临时特性分支（feature/*），完成后通过 Gerrit 审核合并回 main，合并后删除特性分支。
   • 适用场景：迭代快、团队小、依赖自动化测试的项目。

2. Git Flow

   • 核心分支：main（生产环境）、develop（开发环境）。
   • 辅助分支：feature/*（新功能）、release/*（发布准备）、hotfix/*（紧急修复）。
   • 流程：特性分支从 develop 创建，通过 Gerrit 审核后合并回 develop；发布时从 develop 创建 release/*，测试后合并到 main 和 develop。
   • 适用场景：版本周期长、需严格区分生产 / 开发环境的项目。

3. 简化版（适合中小型团队）

   • 核心分支：main（稳定版本）、dev（日常开发）。
   • 临时分支：feature/xxx（从 dev 创建）、fix/xxx（从 main 创建修复，再同步到 dev）。

二、Gerrit 分支管理的核心规则

Gerrit 的关键作用是 **“保护分支不被直接修改”**，所有代码必须经过审核才能合并。核心配置包括：

1. 禁止直接推送到保护分支

重要分支（如 main、develop）必须设置为 “不允许直接推送”，强制通过 Gerrit 审核。

• 配置路径：Gerrit 网页 → 项目 → Branches → 选择分支（如 refs/heads/main）→ 编辑权限。
• 关键权限：将 Push 权限设置为 DENY（拒绝所有人直接推送），仅允许通过 Push Merge（审核后合并）。

2. 强制代码审查后合并

配置分支的 “必须通过审核” 规则：

• 开启 Code-Review 标签：要求至少 1 名审核者打 +2 批准（通过 Project Settings → Labels → Code-Review 配置）。
• 可选：开启 Verified 标签（需通过自动化测试，如 Jenkins 构建成功后打 +1）。

三、分支操作流程（结合 Gerrit）

以 “从 dev 分支创建特性分支，最终合并回 dev” 为例，完整流程如下：

1. 创建本地分支并开发

bash

# 拉取最新的 dev 分支
git checkout dev
git pull origin dev

# 创建特性分支（命名规范：feature/功能名-开发者）
git checkout -b feature/user-login-zhangsan

# 开发完成后提交（遵循“单次提交单一变更”原则）
git add .
git commit -m "[Feature] 实现用户登录功能

- 实现账号密码密码校验
- 添加登录状态缓存"

2. 推送到 Gerrit 待审核

Gerrit 要求不直接推送到目标分支，而是推送到特殊的 refs/for/目标分支 引用（Gerrit 会创建一个审核任务）：

bash

# 推送到 Gerrit，目标分支为 dev（审核通过后才会合并到 dev）
git push origin HEAD:refs/for/dev

• 推送成功后，Gerrit 网页会生成一个 Change-Id（如 I123456...），用于跟踪该审核任务。

3. 审核与修改

• 审核者在 Gerrit 网页查看代码，通过 Code-Review 标签反馈：
  • +1：初步认可（非必需）；+2：最终批准（必需）；-1/-2：需要修改（附带原因）。
• 若需修改，本地直接提交新的变更（无需创建新分支），再次推送到相同的 refs/for/dev：

  bash

  # 修改后提交（使用 --amend 保持一个提交，避免冗余）
  git add .
  git commit --amend  # 补充修改信息
  git push origin HEAD:refs/for/dev  # 推送后，Gerrit 会更新原 Change-Id 的审核任务
  

4. 合并到目标分支

• 当审核通过（获得 Code-Review +2 和 Verified +1），审核者或提交者可在 Gerrit 网页点击 Submit 按钮，代码会自动合并到 dev 分支。
• 合并后，删除本地和远程的临时特性分支：

  bash

  # 删除本地分支
  git checkout dev
  git branch -d feature/user-login-zhangsan
  
  # （可选）删除远程特性分支（若推送过）
  git push origin --delete feature/user-login-zhangsan
  

四、特殊场景处理

1. 热修复分支（紧急修复生产问题）

• 从 main 分支创建 hotfix/xxx 分支，开发后推送到 refs/for/main 审核。
• 合并到 main 后，需将修复同步到 dev 分支（避免后续开发丢失修复）：

  bash

  # 从 main 拉取修复后的代码
  git checkout main
  git pull origin main
  
  # 合并到 dev
  git checkout dev
  git merge main
  git push origin HEAD:refs/for/dev  # 再次审核后合并到 dev
  

2. 分支冲突解决

若特性分支与目标分支（如 dev）有冲突，需先在本地同步目标分支的最新代码：

bash

# 拉取 dev 最新代码
git checkout dev
git pull origin dev

# 切换回特性分支，合并 dev 并解决冲突
git checkout feature/user-login-zhangsan
git merge dev  # 解决冲突后提交

# 再次推送到 Gerrit 审核
git push origin HEAD:refs/for/dev

3. 保护分支的权限精细化

• 对 main 分支：仅允许架构师或技术负责人有 Code-Review +2 权限，其他开发者无直接合并权。
• 对 dev 分支：允许模块负责人审核并合并，降低审核门槛。

五、最佳实践

1. 分支命名规范
   统一命名格式，便于识别分支用途：

   • 特性分支：feature/功能名（如 feature/payment-integration）
   • 修复分支：fix/bug编号-问题描述（如 fix/BUG123-login-crash）
   • 发布分支：release/v1.2.0
   • 热修复分支：hotfix/v1.1.1

2. 定期清理过时分支
   合并后的临时分支（feature/*、hotfix/*）应及时删除，避免分支泛滥。可通过 Gerrit 插件（如 Delete Project）或脚本定期清理。

3. 自动化辅助

   • 配置 Gerrit 钩子（Hook）：提交时自动检查分支命名规范、禁止直接推送到保护分支。
   • 集成 CI/CD 工具（如 Jenkins）：审核前自动运行测试，失败则打 Verified -1，阻止合并。

总结

Gerrit 分支管理的核心是：用 Git 维护分支结构，用 Gerrit 控制合并权限和审核流程。通过禁止直接推送、强制代码审查、规范分支命名和生命周期，既能保证主分支的稳定性，又能支持团队高效协作。关键是根据项目规模选择合适的分支策略，并严格执行 “审核后合并” 的规则。