如何使用GitLab在Linux上进行代码审查

在 Linux 上使用 GitLab 进行代码审查的实操指南

一 环境与权限准备

• 安装与初始化 GitLab（如尚未部署）：在 Linux 主机安装 GitLab CE/EE，编辑 /etc/gitlab/gitlab.rb 设置 external_url，执行 gitlab-ctl reconfigure 使配置生效；初始管理员密码位于 /etc/gitlab/initial_root_password，该文件在首次 reconfigure 后 24 小时自动删除，请尽快登录并修改密码。
• 客户端准备：安装 Git，配置全局身份与 SSH 密钥，并将公钥添加到 GitLab 个人设置，以便通过 SSH 克隆与推送。
• 角色与权限：为团队分配 Guest/Reporter/Developer/Master/Owner 等角色，通常将 Developer 用于日常提交，Master/Owner 负责合并与审批。

二 标准审查流程

• 分支策略：基于 Git Flow 或团队约定，从 dev/main/master 创建 feature/ 分支进行开发，避免直接向受保护分支推送。
• 提交与推送：在本地完成实现与自测后，提交并推送到远端 feature 分支。
• 创建合并请求 MR：在 GitLab 项目页面选择源分支与目标分支，填写 标题/描述，使用 @ 指派审阅者，可设置 必需审批数量；描述中建议说明变更目的、测试步骤、影响范围，并关联 Issue。
• 在线评审：审阅者在 MR 页面通过 Inline/Side-by-side 查看差异，发表评论、建议修改或批准；作者根据反馈迭代修改并推送，评论线程可持续讨论。
• 冲突处理：若合并存在冲突，开发者在本地将目标分支（如 dev）合并到 feature 分支解决冲突后重新推送，MR 会自动更新差异。
• 通过并合并：满足审批与流水线要求后由维护者合并，必要时删除已合并的 feature 分支。

三 保障质量的自动化与规则

• 分支防护：在项目 Settings → Repository → Protected Branches 中，为目标分支（如 main/dev）配置策略：仅允许 Maintainers/Masters 合并，必要时将 Allowed to push 设为 No one，强制通过 MR 审查与 CI 通过后再合并。
• CI/CD 门禁：在仓库根目录添加 .gitlab-ci.yml，配置单元测试、构建、静态检查等作业；只有流水线成功才允许合并。示例：

  stages:
    - test
    - build
  
  sast:
    stage: test
    image: registry.gitlab.com/gitlab-org/security-products/sast:latest
    artifacts:
      paths: [gl-sast-report.json]
  
  build:
    stage: build
    script:
      - echo "Running build..."
  

• 代码规范与质量门禁：在 CI 中集成 Checkstyle/PMD/ESLint 等工具，或使用 SonarQube 质量门禁；结合 CODEOWNERS 文件指定目录/文件的强制审批人，确保关键路径受审。
• IDE 与本地效率：使用 IntelliJ IDEA GitLab 插件 或 VS Code 扩展 在 IDE 内创建、查看与回复 MR 评论，减少上下文切换。

四 提效扩展与常见问题

• AI 辅助评审：通过 Webhook + 自建服务 + LLM 的方式为 MR 自动生成评审意见（示例项目 satomic/ai-code-review），可用于初筛问题、提升覆盖率；注意网络连通、Token 权限与合规要求。
• 评审沟通与拆分：将过大的 MR 拆分为约 200 行变更的小 MR，降低认知负担；对复杂问题优先线下沟通，结论回填至 MR 评论；使用 Duo Chat 等助手快速定位变更背景与影响。
• 常见问题速解：
  • 无法推送受保护分支：检查 Protected Branches 策略与自身角色权限。
  • MR 无法合并：确认 审批数达标、流水线成功、无 冲突 且目标分支未被锁定。
  • 评审意见未生效：在 MR 线程中点击 Resolve thread 标记已解决，或重新推送后刷新差异。