GitLab Merge Request 实战指南：从分支管理到代码审查的完整流程

我第一次在GitLab上发起Pull Request，是在刚进团队没多久的时候。那时候大家还习惯直接往 develop 分支推代码，觉得流程越短越高效。直到有次我改了一个配置项，没经过任何人 review 就推了上去，结果测试环境整个服务起不来。主管在群里问"谁动了配置"，我战战兢兢承认之后，他把我拉到屏幕前，教我怎么用 GitLab 的 Merge Request 把每一次改动变成一次可讨论、可追踪、可回滚的"提交仪式"。

先说一个容易绕晕的点：你在搜索引擎里敲"gitlab pull request"，其实 GitLab 官方叫法是 Merge Request（MR）。GitHub 叫 Pull Request，GitLab 叫 Merge Request，本质都是"我请求把我分支上的改动合并到目标分支"，只是平台叫法不同。所以你在 GitLab 的菜单栏、文档、API 里看到的更多是 merge request。这篇文章我会把 GitLab 的 Pull Request（下文统一叫 MR）完整拆一遍：它到底解决了什么问题、一个 MR 从创建到合并要经过哪些环节、常见的报错怎么排查。内容偏实操，适合刚接触 GitLab 的团队，也适合已经在用但没系统梳理过这套流程的个人开发者。

1. 从"直接推代码"到"Pull Request"：思路转变才是核心

1.1 先澄清一个叫法：GitLab 里为什么是 Merge Request

很多新手第一次在 GitLab 上找 Pull Request，找半天找不到，后来才发现菜单上写的是 Merge Request。这个差异其实有历史原因：GitHub 的协作模型默认是"fork + pull"，我把仓库 fork 一份，改完代码，向原仓库发起一个"拉取请求"，请求对方把我的改动拉过去；GitLab 的默认模型更偏向"同一个仓库内开分支"，我改完代码，请求管理员或审核人把这个分支"合并"回主分支。两条路径殊途同归，但在 GitLab 里你只需要记住一个词：Merge Request。

搜索的时候，GitLab 自己的搜索框其实能识别 pull request 和 merge request 两种写法，但文档、API 参数、命令行提示里统一是 merge request。如果你在 GitLab 上跟同事说"发个 PR"，大家通常也能听懂，但正式流程里更标准的说法还是"提个 MR"。

1.2 MR 机制解决的三件事：代码质量、过程留痕、降低合并冲突

为什么要用 MR，而不是直接把代码推到主干？我觉得核心原因有三个。

第一，强制做代码审核。 写代码的人对自己的代码天然有盲区，逻辑漏洞、边界情况、风格问题，靠自己 review 常常发现不了。有了 MR，改动在合并之前会暴露给至少一个其他成员，别人可以在具体某一行代码上直接评论，说"这里有个并发问题"或者"这个命名看不懂"。这个过程不需要面对面，不需要开会，异步就能完成。团队里哪怕只有一个认真看代码的人，整体质量都能提升一个档次。

第二，过程留痕。 直接推代码，改了什么、为什么改，全靠提交记录猜。MR 把整个变化过程变成了一个完整档案：背景描述、代码 diff、讨论记录、CI 结果、审批人、合并时间，全部绑在一起。三个月后你回溯一个问题，打开当时的 MR，所有信息都在，不用翻聊天记录，不用问"这代码谁写的"。

第三，降低合并冲突的概率。 直接往主干推代码，多人并行开发时冲突是家常便饭。MR 机制配合"小步提交、频繁合并"，每个分支的生命周期很短，改动范围小，冲突自然少。就算有冲突，MR 界面也会提前标出来，让你在合并前解决，而不是在上线前爆发。

拿图书馆打比方：直接推代码就像所有人围着一本书同时往上写，你写一段我写一段，最后谁也看不清；MR 就像借书登记、批注审核、审批入馆，每个人都能看到你改了哪页、为什么改、谁批准了这次修改。

1.3 什么场景必须用 MR，什么场景可以不用

MR 不是银弹，不是所有项目都需要。我个人经验是这么分的：

• 需要用的场景：多人协作的正式项目；有 main、master、develop 这类公共分支的项目；开源项目；公司要求审计留痕的项目。只要团队人数超过两个，我建议至少在主干分支上开启"禁止直接推送"的保护策略，强制走 MR。
• 可以不用的场景：个人玩具项目、单分支试验项目、一次性脚本仓库、只有你自己提交代码且不需要 review 的内部工具。强行在这些项目上走 MR 反而增加负担。

如果你在纠结"到底要不要上 MR"，我的建议很直接：先给主干分支加上保护，禁止直接 push，逼自己走一次完整 MR 流程。走完之后你再决定要不要保留这套限制。多数人的结果是——回不去了。

2. 核心细节解析与实操要点：从创建分支到 MR 被合并的全过程

2.1 分支管理和命名规范：没有规范，MR 就是一团乱麻

MR 的前提是分支，分支如果乱，MR 的质量肯定高不了。我见过不少团队，分支名字千奇百怪：test1、aaa、dev、111，打开 MR 列表根本不知道这个改动是干什么的。这里推荐一套简单实用的命名思路：

命名的时候把功能点或缺陷编号带上，比如 `fix/JIRA-123-login-redire