为什么 Github 叫 Pull Request，Gitlab 叫 Merge Request?

同样是 MR 合并请求，为什么 Github 叫 Pull Request，Gitlab 叫 Merge Request?

这是一个很好的命名溯源问题。两者功能上基本等价，但命名角度不同，背后有Git工作流的历史脉络。

1. 核心差异

	GitHub: Pull Request (PR)	GitLab: Merge Request (MR)
命名重心	强调动作发起方：请求上游"拉取"我的代码	强调最终结果：把分支"合并"进去
隐喻模型	分布式贡献模型（fork → 上游 pull）	集中式协作模型（分支 → 目标分支 merge）
对应Git命令	git request-pull / git pull	git merge

2. 为什么这么命名

2.1. GitHub 的 "Pull" 来自 Git 原生语义

Git 早期是分布式、无中心的协作模型。你 fork 了别人的仓库后，你的代码在你的远程仓库里，上游维护者看不到也访问不到。于是贡献者说："请你从我的仓库 pull（拉）一下我的改动"——这就是 git request-pull 命令的本意。

GitHub 把这个交互界面化后，沿用了 request-pull 的语义，叫 Pull Request：请求对方来拉取我的分支。

2.2. GitLab 的 "Merge" 更贴近实际动作

GitLab 早期主打自托管、同一仓库内分支协作的场景（公司内部团队）。大家都在同一个 remote 下开分支，不存在"从别人 fork 仓库拉取"的步骤——真实发生的动作就是：把 feature 分支 merge 到 main。

所以 GitLab 直接用最终动作命名为 Merge Request，更直白，也更贴合它面向企业内部协作的产品定位。

3. 一句话总结

PR 是"过程视角"（请求你来拉我的代码），MR 是"结果视角"（把代码合并进去）。底层做的是同一件事：在代码合入主干前，做评审、CI 检查和合并。

4. Github为什么不改名？

现在的 GitHub 产品形态，明显Merge Request才更符合语义，GitHub 为啥不改名？

4.1. 原因一：并不是不想改，而是改不动

Pull Request并非完全"名不副实"，GitHub 上仍然有大量真实的 fork-based 贡献流：

• 外部贡献者 fork 你的仓库 → 在自己账号下的分支提交 → 向你发 PR
• 这种场景下，你的仓库根本访问不到贡献者的分支，你必须主动从他的远程 pull 他的 ref 下来才能合并 ——"pull" 这个动作是真实发生的。

这这个背景下，改名的成本太高，生态绑定太深，牵一发而动全身。

4.2. 原因二：PR这个术语已经被业界广泛采用

PR(Pull Request)起源与开源社区，经过常年的积累，这个术语已经被行业和各大社区广发采用。提个 PR"、"review PR"、"PR 被 merge 了" 已经是开发者母语。而Github又是全球最大的开发者平台，改名等于让全球开发者换口头禅，收益几乎为零。

恰恰相反的是Gitee、Bitbucket 等平台大多跟随 GitHub 叫 Pull Request；只有 GitLab（以及中国的 Coding 等少数）坚持叫 Merge Request。这个命名差异已经成为技术圈的一个经典梗。