05. GitLab MR 代码审查：Code Review 最佳实践

发表于 2026-11-13 分类于 GitLab

MR 不只是合并代码，更是团队知识传递的质量闸口。创建、审查、讨论、合并的全流程最佳实践，让 Code Review 真正提升代码质量。

「GitLab」系列已发布： 00. GitLab 不只是代码托管：一套 DevOps 平台的 6 大核心能力｜ 01. GitLab 怎么装最省心？Omnibus/Docker/K8s 三种姿势｜ 02. 装完 GitLab 先配啥？管理员视角的初始化设置清单｜ 03. GitLab 角色搞不清？Member/Maintainer/Owner 权限全解｜ 04. 从零建好第一个 GitLab 项目：权限、变量、CI 配置入门｜ 05. GitLab MR 代码审查：Code Review 最佳实践（本文）

MR 不只是合并代码，更是团队知识传递的质量闸口。创建、审查、讨论、合并的全流程最佳实践，让 Code Review 真正提升代码质量。

前置条件

已完成安装部署（第 01 篇），熟悉项目创建与管理（第 04 篇）的基本操作。下面的操作全在 GitLab Web UI 完成。

一、Merge Request 是什么

Merge Request（MR）是 GitLab 最核心的协作功能，类似于 GitHub 的 Pull Request。它不仅限于"请帮我合并代码"，而是包含了一套完整的协作机制：代码审查、CI 检查、讨论沟通、权限控制，全部集成在一个流程里。

flowchart LR
    A[开发分支] --> B{创建 MR}
    B --> C[自动运行 CI]
    C --> D{CI 通过?}
    D -->|否| E[修复问题]
    E --> C
    D -->|是| F[代码审查]
    F --> G{审批通过?}
    G -->|否| H[修改代码]
    H --> F
    G -->|是| I[合并到目标分支]
    I --> J[自动部署]

1.1 MR 的核心价值

代码审查：合并前强制 review，降低 bug 和安全隐患
质量门禁：CI/CD Pipeline 必须通过才能合并
变更记录：每次变更都有迹可循，便于回溯
团队协作：评论、讨论、决策都在 MR 内完成

二、创建 Merge Request

2.1 从分支创建

在 GitLab 页面顶部点击 New Merge Request，选择源分支和目标分支。

sequenceDiagram
    participant Dev as 开发者
    participant GitLab as GitLab
    participant CI as CI/CD
    participant Reviewer as 审查者
    
    Dev->>GitLab: 推送分支到远程
    GitLab->>CI: 自动触发 Pipeline
    CI->>GitLab: 返回状态结果
    Dev->>GitLab: 创建 MR
    GitLab->>Reviewer: 通知代码审查
    Reviewer->>GitLab: 审核并评论
    Dev->>GitLab: 根据评论修改代码
    GitLab->>CI: 重新运行 Pipeline
    CI->>GitLab: 返回通过状态
    Reviewer->>GitLab: 批准 MR
    GitLab->>GitLab: 合并代码

2.2 从 Issue 关联

在创建 MR 时填写 Closes #ISSUE_ID 或 Fixes #ISSUE_ID，合并后 Issue 会自动关闭。

三、MR 页面详解

3.1 基本信息区

标题：简洁描述变更内容
描述：详细说明变更背景、影响范围
分配给：指定审查人
标签：bug、feature、breaking-change 等
里程碑：关联到版本发布

3.2 变更对比区

左侧：目标分支最新代码
右侧：源分支最新代码
中间：diff 高亮显示

3.3 检查项区

检查项	说明
Pipeline 状态	所有 Job 必须通过
变更请求	是否要求代码审查
讨论完成	是否解决所有评论
无冲突	目标分支无冲突
未合并的提交	是否有未合并的提交
构建成功	构建是否通过

四、代码审查流程

4.1 审查要点

flowchart TD
    A[收到 MR 通知] --> B{优先阅读什么?}
    B --> C[变更描述]
    B --> D[代码 diff]
    B --> E[CI 结果]
    
    C --> F{描述清晰?}
    F -->|否| G[评论要求补充]
    F -->|是| H[检查代码]
    
    D --> I{逻辑正确?}
    I -->|否| J[评论指出问题]
    I -->|是| K[检查边界情况]
    
    K --> L{测试覆盖?}
    L -->|否| M[建议补充测试]
    L -->|是| N[批准 MR]

4.2 评论类型

行级评论：针对具体代码行
整体评论：针对整个 MR
建议采纳：一键应用建议代码
解决评论：标记为已解决

4.3 审查最佳实践

及时响应：24 小时内开始审查
建设性反馈：指出问题同时给出改进建议
一次审完：避免分多次评论
关注业务逻辑：不仅看语法，更要看设计
认可优点：好的设计也要肯定

五、合并策略

5.1 三种合并方式

flowchart LR
    subgraph MergeCommit["Merge Commit"]
        A[feature分支] --> D[main分支]
        B[main分支] --> D
        D --> E["合并提交
(保留历史)"]
    end
    
    subgraph FF["Fast-Forward"]
        C[feature分支] --> F[main分支]
        F --> G["直接前进
(无合并记录)"]
    end
    
    subgraph Squash["Squash Merge"]
        H[多个提交] --> I["压缩为一个
(整洁历史)"]
    end

策略	适用场景	优点	缺点
Merge Commit	保留完整历史	清晰看到分支合并点	历史较杂乱
Fast-Forward	临时分支	历史简洁线性	丢失分支信息
Squash	小功能迭代	提交历史整洁	丢失中间提交

5.2 设置方法

项目 → Settings → Merge requests：

Merge commit message：合并时的提交信息模板
Remove source branch：合并后删除源分支

六、MR 模板

6.1 项目级模板

在项目根目录创建 .gitlab/merge_request_templates/：

<!-- .gitlab/merge_request_templates/default.md -->

## 变更概述


简要描述本次变更的内容和目的。

## 关联 Issue


Closes #ISSUE_ID

## 变更类型


- [ ] feat: 新功能
- [ ] fix: 修复 bug
- [ ] docs: 文档变更
- [ ] style: 代码格式（不影响功能）
- [ ] refactor: 重构
- [ ] test: 测试相关
- [ ] chore: 构建/工具相关

## 检查清单


- [ ] 单元测试通过
- [ ] 集成测试通过
- [ ] 代码格式检查通过
- [ ] 已更新相关文档
- [ ] 无安全风险（无硬编码密钥、无注入）

## 截图/录屏


（如有 UI 变更，请附上截图）

6.2 使用模板

创建 MR 时下拉菜单选择模板，自动填充内容。

七、高级功能

7.1 Draft MR

标记为 Draft 的 MR 不会触发自动通知，适合 WIP（Work In Progress）阶段。


# 创建 Draft MR
curl --request POST \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --data "source_branch=feature/login" \
  --data "target_branch=main" \
  --data "title=DRAFT: feat: 实现登录功能" \
  --data "work_in_progress=true" \
  "https://gitlab.example.com/api/v4/projects/$PROJECT_ID/merge_requests"

7.2 Auto Merge

设置 MR 满足条件后自动合并：

Pipeline 通过
至少 N 人审批
无评论待处理

7.3 Approval Rules

项目 → Settings → General → Merge requests → Approval rules：

定义哪些人必须审批
设置最小审批人数
指定排除的审批人

八、MR 状态流转

stateDiagram-v2
    [*] --> Created: 创建 MR
    Created --> UnderReview: 开始审查
    UnderReview --> ChangesRequested: 要求修改
    ChangesRequested --> UnderReview: 修改后重新提交
    UnderReview --> Approved: 审批通过
    Approved --> Merging: 合并中
    Merging --> Merged: 已合并
    Merging --> MergeFailed: 合并失败
    MergeFailed --> UnderReview: 重新处理

九、常见问题

9.1 如何解决冲突？

本地拉取目标分支最新代码
合并到源分支解决冲突
推送更新后的源分支
GitLab 自动更新 MR diff

9.2 如何撤销合并？

软撤销：在新分支上 revert 提交
硬撤销：回滚分支到合并前状态（需谨慎）

9.3 如何禁止某些人合并？

在项目设置中配置保护规则，指定允许合并的角色。

十、文章引用

📌 本文首发于微信公众号 【运维知识点滴】——专注运维实战干货，微信搜索“运维知识点滴”或扫下方二维码关注，更新不迷路。
📎 微信原文：05. GitLab MR 代码审查：Code Review 最佳实践

微信公众号【运维知识点滴】	微信小程序【A5单据合并&大试卷拆分转A4打印】

运维实战干货 · 关注追更	Word 转 PDF · 试卷/发票打印神器 · 免费

💡 小程序【A5单据合并&大试卷拆分转A4打印】是干嘛的？ 一个 Word 转 PDF 的打印神器，专治“文档版式和打印机对不上”：

A3 试卷打不出来？ 学校发的电子版试卷多是 A3，家用打印机只吃 A4——上传 Word 一键转换：可缩到一页 A4（页数不变），也可对半拆成两张 A4（1:1 原大、字更清晰），两种模式自选；

版式不乱：真实渲染引擎原样转换、绝不重排内容，转出的 PDF 和原 Word 排版一致，公式/表格/图片不跑版；

两张 A5 单据拼一张 A4：出租车票、火车票等报销凭证拼版后，一次打印、整齐粘贴；

隐私省心：无需注册，转换结果留存 5 天、最多下载 5 次即自动删除，不留任何历史记录；

微信扫码即用，免费、免安装，支持 doc / docx（≤50MB）。
原文发布于 2026-08-14

上一篇：04. 从零建好第一个 GitLab 项目：权限、变量、CI 配置入门