小丸子书单GitLab 上待久了你会发现，大家嘴上挂着的 Pull Request，在 GitLab 界面里实际叫 Merge Request。标题里的 pull requets 大概率是手误，但想表达的东西很明确：代码协作里最核心的那一环——提交合并请求、组织 Code Review、把分支安全地合回主干。我这些年带团队做代码托管迁移，被问得最多的也是这条链路。这篇文章我就把 GitLab 上从零跑通 Pull Request（下面统一按 GitLab 习惯叫 MR）的完整思路和实际操作写出来，包括环境准备、分支策略、实操步骤、常见坑点，以及和 CI/CD 怎么配合。不管你是刚把团队代码迁到 GitLab 的负责人，还是第一次在 GitLab 上提 MR 的研发新人，这篇都能直接对着用。
1. 理解 Merge Request 机制
1.1 别被名字绕晕：Pull Request 和 Merge Request 是什么关系
先说个很常见的认知差。GitHub 叫 Pull Request，GitLab 叫 Merge Request，代码托管平台不同，名字不同，但解决的是同一个问题：你想把某个分支的改动合到另一个分支（通常是主干），不能直接 push 上去，而是先在平台上发起一个申请，让相关人员审查这批改动，确认没问题后再执行合并。这个机制背后的核心价值不是"合并"这个动作，而是"审查"这个过程。
GitLab 之所以叫 Merge Request，是因为它的设计更强调"请求被合并"这个结果状态，并且从诞生起就把它和 Issue、CI/CD、权限模型深度绑在了一起。实际使用中，一个 MR 可以关联 Issue、触发流水线、指定 reviewer、做多轮讨论，甚至可以设置合并前必须通过的检查项。这些能力如果只靠直接 push 分支来干活，是完全没有的。
我遇到过不少团队，刚迁到 GitLab 时还是"所有人都能 push 主干"的野路子，代码出问题都不知道谁改的。后来把主干设成保护分支、强制走 MR 流程之后，代码质量和出问题后的追溯能力明显上了一个档次。理解了这个机制背后的"审查"本质，后面所有操作环节你都能明白为什么要这么做。
1.2 分支策略：MR 能顺利流转的前提
MR 不是孤立的功能，它和你采用的分支策略强相关。常见的分支模型有三种。第一种是 GitHub Flow，主干长期存在，开发分支从主干拉出，提交 MR 合回主干，适合持续交付的互联网产品。第二种是 Git Flow，有 main、develop、release、feature、hotfix 多类分支，适合有固定发版周期的项目。第三种是 GitLab Flow，在 GitHub Flow 基础上增加了环境分支（如 staging、production），适合需要按环境逐级上线的场景。
分支策略怎么选，直接影响 MR 的粒度和审查效率。比如团队做的是每周发版一次的 ToB 产品，用 Git Flow 更合适，MR 从 feature 到 develop，再从 develop 到 release，每一层的合并都是一次质量闸门。而如果是 SaaS 产品一天发版多次，GitHub Flow 更省事，MR 直接打到 main，配合 CI 保证质量。
我个人比较推荐中小团队用 GitLab Flow 的简化版：main 分支始终可部署，功能从 main 拉分支，测试环境直接用该分支的 MR 流水线产物，验收通过后再合回 main。这样 MR 既承担了代码审查的职责，又承担了环境发布的入口。分支策略不在多，在于团队能不能一致执行，定了就写进 README 或者 CONTRIBUTING 文档里，让 MR 模板自动带上说明。
1.3 保护分支与权限模型
MR 能落地的另一个前提是权限模型要设对。GitLab 里通过保护分支（Protected Branch）来限制谁能直接 push、谁能合并 MR。以 GitLab 默认的 Protected 设置为例，main 分支默认是保护状态，只有 Maintainer 及以上角色才能直接 push，其他人只能通过 MR 合并。
这里有一个非常关键的权限级别认知：Guest、Reporter、Developer、Maintainer、Owner 这五个角色，权限逐级递增。Developer 可以创建分支、提交 MR、处理 review 意见，但没有权限合并到受保护的主干分支；Maintainer 可以合并受保护分支的 MR，也可以调整保护规则。实际设置保护分支时，可以把"允许合并"设置为 Maintainer，把"允许推送"设置为"仅 Maintainer"或者完全不开放，具体看团队的自治程度。
设置保护分支的操作路径是：项目设置 -> Repository -> Protected branches，输入分支名，选择允许合并和允许推送的角色。这里有三个值得注意的点。第一，保护分支的规则支持通配符，比如 release/* 可以一次保护所有 release 前缀的分支。第二，如果设了 "Allowed to merge" 但没设 "Allowed to push"，Developer 角色还是能通过 MR 合入代码。第三，紧急修复时如果需要直接 push 主干，不用改保护规则，可以临时在 MR 界面勾选 "Allow commits from members who can merge" 或者使用 Maintainer 账号操作，但事后要在周会上复盘为什么走了紧急通道。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 准备一套能跑通 MR 的环境
2.1 服务端：用 Docker 快速部署 GitLab
要正经用 MR，先得有一个能跑的 GitLab 实例。很多团队的内网 GitLab 都是拿 Docker 部署的，原因很直接：一条命令能跑起来，升级和管理都相对省心。GitLab 官方提供了社区版镜像 gitlab/gitlab-ce，部署时需要注意几个关键配置，否则后患无穷。
最核心的一个坑是 external_url。GitLab 会把 external_url 写进项目的 clone 地址和很多内部链接里，所以必须设成容器外部能访问到的地址，比如 http://gitlab.example.com 或者 `http://192.