为什么「Pull Request」这个名字让人困惑？一文揭秘其历史由来

发表于 分类于 ，

为什么「Pull Request」这个名字让人困惑？一文揭秘其历史由来

引言

作为开发者，你是否曾经疑惑过：为什么叫「Pull Request」而不是「Merge Request」？它和 git pull 命令有什么关系吗？如果你也有这些疑问，那么这篇文章就是为你而写的。

让我们一起探索这个令无数开发者困惑的术语背后的历史故事。

术语混淆的根源

最常见的误解

许多开发者（包括经验丰富的程序员）都会有这样的困惑：

1
2
3
4
5
# 开发者的内心独白
git pull  # 这是从远程仓库拉取代码
# 既然如此，"Pull Request" 应该也和拉取代码有关吧？

# 真相：两者完全没有关系！🤯

让我们澄清一下：

  • git pull → 从远程仓库拉取代码到本地
  • Pull Request → 请求将你的分支合并到目标分支

看到了吗？完全是两回事！

历史起源

GitHub 的历史性命名决定

时间线: 2008年，GitHub 刚刚诞生

历史背景: 在那个年代，开源协作还很原始，贡献者的工作流程是这样的：

  1. Fork（分叉）项目到自己的账户
  2. 在自己的 fork 中进行修改
  3. 请求原项目维护者”拉取”（pull）这些更改

那个年代的开源协作模式

1
2
3
4
5
6
7
8
传统的协作流程：

贡献者的Fork仓库 ←─── Fork ───── 原始项目仓库
        │                           ↑
        │ 在fork中修改代码            │
        │                           │
        └─── 发邮件/发补丁 ─────────────┘
             "喂！请pull我的更改"

在这个模式中，逻辑是这样的：

  • 项目维护者需要「pull」（拉取）贡献者的更改到主仓库
  • 贡献者发出的是一个「request」（请求）
  • 两个词组合起来就是：「Pull Request」

原来如此！这就是名字的由来。

GitHub 的革命性创新

GitHub 的天才之处在于将复杂的邮件协作流程变成了简单的网页操作：

1
2
3
4
5
6
GitHub 简化后的流程：

1. 🍴 Fork 项目到你的账户
2. 🌿 创建功能分支，提交更改
3. 🖱️ 点击 "Create Pull Request" 按钮
4. 👥 维护者在网页上审核和合并

看起来简单多了，对吧？但名字却保留了下来。

不同平台的命名选择

GitLab 的明智选择：Merge Request

当 GitLab 在 2011 年出现时，他们做了一个更聪明的决定：

1
2
3
4
GitLab 的命名逻辑：
你的真实意图：    合并（Merge）你的分支到主分支
你发出的动作：    请求（Request）
因此应该叫：     Merge Request ✨

这个命名显然更合理：

  • ✅ 语义清晰：直接说明你想做什么（合并）
  • ✅ 避免混淆：和 git pull 毫无歧义
  • ✅ 易于理解：新手一看就懂

但可惜的是，GitHub 已经先入为主了。

其他平台的命名

平台 术语 说明
GitHub Pull Request (PR) 历史原因，沿用至今
GitLab Merge Request (MR) 更直观的命名
Bitbucket Pull Request 跟随 GitHub
Azure DevOps Pull Request 跟随 GitHub
Gitee Pull Request 跟随 GitHub

为什么这个”不准确”的命名能存活至今？

1. 先发优势的力量

1
2
3
4
时间线：
2008年 GitHub诞生 → Pull Request概念传播 → 2011年 GitLab推出Merge Request
       ↓
但为时已晚，开发者已经习惯了"Pull Request"

2. 网络效应的威力

  • 🏆 GitHub 统治地位：作为全球最大代码托管平台
  • 🧠 认知惯性：百万开发者已经习惯这个术语
  • 🔄 跟随效应：其他平台为了降低学习成本也采用相同术语

3. 生态系统的锁定

1
2
3
4
5
6
7
8
9
10
11
12
13
# 整个工具链都在使用这个术语
gh pr create          # GitHub CLI
git hub pull-request  # Hub工具

# CI/CD 配置无处不在
# GitHub Actions
on:
  pull_request:
    branches: [main]

# Azure DevOps
trigger:
  pr: [main]

想改？太难了，成本太高！

实际的工作流程

开发者的日常工作流

1
2
3
4
5
6
7
8
9
10
11
12
# 1. 创建功能分支
git checkout -b feature/awesome-feature

# 2. 写代码，测试，提交
git add .
git commit -m "feat: 添加超酷的新功能"

# 3. 推送到远程仓库
git push origin feature/awesome-feature

# 4. 在GitHub网页上点击 "Create Pull Request"
# 💡 注意：这里你实际在做的是"请求合并"，而不是"拉取"

看到讽刺的地方了吗？我们用 git push（推送）代码，然后创建一个叫 “Pull”（拉取）Request 的东西。

CI/CD 配置中的体现

1
2
3
4
5
6
# .github/workflows/ci.yml
on:
  pull_request:    # 当创建/更新 PR 时触发
    branches: [main]
  push:           # 当推送到 main 时触发
    branches: [main]
1
2
3
4
5
6
7
8
9
10
# CNB 配置
pull_request:     # PR 验证流水线
  push:
    stages:
      - name: 测试构建

master:          # 生产部署流水线
  push:
    stages:
      - name: 部署到生产

如何更好地理解

转换你的思维模型

❌ 新手的错误理解：

1
Pull Request = 和 git pull 命令相关的请求

✅ 正确的理解方式：

1
2
3
4
Pull Request = 请求项目维护者"拉取"（即合并）我的更改

更直白的翻译：
Pull Request ≈ Merge Request ≈ 「合并请求」

🧠 记忆小技巧

历史情景法：想象你回到2008年，给 Linux 内核维护者写邮件：

“嗨 Linus，我修复了一个 bug，请 pull（拉取整合）我的更改到主分支。”

现代直译法：遇到 Pull Request 就直接翻译成：

“我要提交一个合并请求，请审核我的代码。”

这样就不会再困惑了！

对新手的建议

📚 推荐学习路径

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
新手学习Git协作的最佳顺序：

第一步：Git 基础命令
├── git clone（克隆仓库）
├── git pull（拉取更新）
├── git push（推送代码）
└── git merge（合并分支）

第二步：分支管理
├── 理解分支的概念
├── 创建和切换分支
└── 合并分支策略

第三步：团队协作
├── Fork 工作流
├── 代码审核流程
└── 冲突解决

第四步：Pull Request
└── 现在你就能理解为什么叫这个名字了！

术语对照表

场景 GitHub 术语 GitLab 术语 实际含义
请求合并 Pull Request Merge Request 请求将分支合并到目标分支
下载代码 git pull git pull 从远程仓库拉取代码
上传代码 git push git push 向远程仓库推送代码

结论

总结：一个历史包袱，但我们得学会接受

「Pull Request」确实是一个容易让人困惑的术语，但现在你知道了它的来龙去脉。虽然 GitLab 的「Merge Request」更加直观明了，但历史的轮子已经滚动，「Pull Request」已经成为了行业标准。

🎯 核心要点记忆卡片

概念 要点
💡 本质理解 Pull Request ≠ git pull，而是「请求合并我的代码」
📚 历史由来 2008年GitHub沿用了邮件时代的术语
🌍 现状认知 不同平台术语不同，但概念完全一样
🧠 记忆技巧 直接翻译成「合并请求」就对了

💌 给初学者的话

下次当你看到「Pull Request」时，不要再纠结这个名字了。直接在脑海中翻译成「合并请求」，专注于理解其背后的协作流程，这才是最重要的。

毕竟，叫什么名字不重要，重要的是这个机制让全世界的开发者能够更好地协作！ 🚀

📝 写在最后

希望这篇文章能够彻底解决你对「Pull Request」命名的困惑。如果你身边还有被这个术语搞懵的朋友，不妨把这篇文章分享给他们！

有其他Git协作相关的问题？欢迎在评论区继续讨论！ 💬