PR中的P为什么是pull而非push？

修改一段代码，push到远程，创建PR，等待维护者评审合并到主干。这里PR，为什么叫 Pull Request ，而不是 Push Request？

回答上面问题之前，要先理解**"Pull"** 这个词在 Git 里有双重含义：

git pull 、git push 属于具体的git命令行操作；Pull Request 不是git操作，是一个社交动作。

为什么叫 Pull Request（拉取请求）而不是 Push Request，需要从Git 的底层逻辑和协作的安全模型两个角度来看。

在 GitHub/GitLab 等平台上，"发起 PR"并不是一个 Git 命令行操作，而是一个平台层面的动作。具体步骤如下：

你本地操作：
- 你在本地分支修改代码。
- git add .
- git commit -m "fix bug"
- git push origin your-branch （注意：这里你只是推送到你自己的远程分支，或者你在 Fork 后的仓库中）
平台操作（发起 PR）：
- 打开 GitHub/GitLab 网页界面。
- 点击 "New Pull Request" 按钮。
- 选择对比分支：
  - Base branch（目标分支）：比如 main（你想合并进去的地方）。
  - Compare branch（源分支）：比如 your-branch（你刚才推送代码的地方）。
- 填写标题、描述，点击 "Create Pull Request"。

此时，PR 就发起了，它本质上是一个通知+链接，告诉维护者："请看这两个分支的差异，如果没问题，请把它们合并。"

虽然你确实执行过 git push操作，将代码提交到自己的远程分支。但PR 的核心语义是"请求对方来拉取你的代码"，你没有权限直接将代码写入(push)到别人仓库。

操作	谁主动？	权限要求	安全性
Push	你主动推送到别人仓库	你需要有写权限（Write Access）	❌ 高风险：任何人都能直接改主分支，容易出错或被恶意注入
Pull Request	你请求别人从你这里拉取	你只需要有读权限或对自己 Fork 仓库的写权限	✅ 高安全：维护者控制是否合并，经过审查后才生效

具体来说：

你不能直接 Push 到别人的主分支
- 在开源项目或大型团队中，普通开发者没有权限 直接 git push 到 main 分支。
- 如果你尝试 git push origin main，Git 会拒绝你："Permission denied"。
所以你把代码推送到"你能控制"的地方
- 要么是你 Fork 后的个人仓库（如 github.com/yourname/project）。
- 要么是你自己在原仓库中创建的一个特性分支（如 feature/login），你有这个分支的写权限。
然后你"请求"维护者来 Pull 你的代码
- 你通过 PR 说："我的代码已经准备好了，放在我的分支里，请你（维护者）从我的分支 **拉取（Pull）**这些更改，并合并到你的主分支中。"
- 维护者点击 "Merge" 按钮时，GitHub 后台实际上是在执行类似 git pull 的操作，将你的更改整合进主分支。

问题	答案
发起 PR 的流程	在网页上点击"Create Pull Request"，指定源分支和目标分支，生成一个可审查的代码变更请求。
为什么叫 Pull Request？	因为你没有权限直接 Push 到主分支，所以你请求维护者从你的分支拉取（Pull）代码并合并。这是一种被动式、受控的协作方式，确保代码经过审查。
我明明 push 了啊？	你 push 的是你自己的分支，不是主分支。PR 是连接"你的分支"和"主分支"的桥梁。

我们可以从动作发起者 和数据流向两个维度来梳理这三者关系。

操作	谁主动？	数据流向	是否需要审查？
git pull	你	远程 → 本地	否（自动同步）
git push	你	本地 → 远程	否（直接上传）
Pull Request	你发起，维护者执行	你的分支 → 主干分支	是（核心目的）

发起者：你自己（开发者），但执行合并动作的是维护者。
方向：你的远程分支 → 目标远程分支（如 main）。
本质：这不是一个 Git 命令，而是一个社交/管理动作 。
- 你说："我的代码在我的分支里，请你（维护者）把它拉（Pull）进主干。"
- 维护者审查后，点击 Merge，GitHub/GitLab 后台实际上执行了一次类似 pull 或 merge 的操作，将你的代码整合进主干。