上游 · 理解本功能前需先掌握的（4）：
下游 · 依赖/承接本功能的（3）：
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
代码写好了，怎么把它「正式交上去」并让别人放心地合入？拉取请求（Pull Request）就是 GitHub 协作的心脏：它把「提议改动、讨论沟通、合并代码」三件事打包在一起。就像你交作业时要先举手说明、给同学评审、最后老师才签字一样。没有它，多人改同一份代码就会乱成一团。
历史背景 · 它为什么诞生诞生于 2008/2010
诞生此前分布式贡献靠"发邮件请维护者拉取你的仓库"（integration-manager模式），过程割裂。GitHub上线即提供简单PR系统，让"把分支/提交合并到主仓库"可视化。2010年8月31日官方宣布Pull Requests 2.0：上线两年已产生20万次PR，故升级为"活的讨论"。
演进PR从"合并请求"变为完整的代码评审平台：2.0引入讨论视图（评论、跟进提交、逐行注释交织）、revision-aware、与Issues集成；2011年GitHub Flow将其用于内部代码评审，SCM从"补丁邮件时代"进入"评审平台时代"。
历史教训
把原本零散的协作动作（提交、评审、讨论、合并）收敛为一个对象，能大幅降低沟通成本；平台化是工具演进的自然方向——从协议到评审到流程治理层层封装。
功能介绍
拉取请求（Pull Request，简称 PR）是 GitHub 的核心协作机制。官方定义是：用 Pull Request 来提议、讨论并合并 GitHub 上的变更（Use pull requests to propose, discuss, and merge changes on GitHub）。它的原理是让 GitHub 对比你所在的分支（head branch，即改动来源分支）与目标分支（base branch，即要被合入的分支），把差异清楚地展示出来。PR 不只是「提交代码」，它自带讨论区，团队成员可以逐行评论、提意见、@ 提醒相关人员；它还包含自动检查状态（如 CI 测试是否通过）。你可以创建草稿拉取请求（Draft Pull Request），标记为「还没做完，先别合并」。PR 还能与问题（Issue）关联，例如在描述里写「fixes #123」，合并时就会自动关闭对应的问题。
核心术语
拉取请求（Pull Request）来源分支（Head Branch）目标分支（Base Branch）草稿拉取请求（Draft Pull Request）问题（Issue）
适用场景
- 当你的功能分支开发完成、想合入主分支时，创建 PR 并请同事评审。
- 当你想参与开源项目、把 fork 副本中的改动提议回上游时，向原仓库发 PR。
- 当改动还没做完、但想提前让团队看思路时，用草稿 PR（Draft Pull Request）。
- 当修复某个 bug 时，在 PR 描述中写 fixes #问题编号 让合并时自动关掉该问题。
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 在你所在的仓库页面点击 Pull requests 标签 → New pull request。
- 选择 base（合入目标分支）和 compare（改动来源分支），点击 Create pull request。
- 填写标题与描述，必要时关联 Issue，点击 Create pull request 提交。
- 等待评审：回应评论 → 修改代码推送到同一分支 → 评审通过后点 Merge pull request 合并。
⌨️ 命令行 (进阶)
git checkout -b feature-xgit commit -am "feat: xxx"git push origin feature-xgh pr create --base main --head feature-x --title "xxx"
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 流程承接分支（Branch） | PR 比较 head branch 与 base branch，先懂分支 |
| 流程承接复制仓库（Fork） | 无写权限时通过 fork 后提 PR 回流变更 |
| 流程承接问题（Issue） | PR 中用 fixes: 关键词可自动关闭关联 issue，先懂 issue |
| 流程承接依赖安全：Dependabot（依赖机器人） | Dependabot security updates 自动开 PR 修漏洞，产出 PR |
| 流程承接代码评审（Code Review） | PR 打开后进入评审环节 |
| 包含从属Projects 看板（Projects Kanban） | PR 也是项目 items 之一 |
| 流程承接自动化部署：GitHub Actions（动作） | PR 事件触发 CI 检查，先懂 PR 再理解自动化触发 |
官方文档
小结
SUMMARY
PR 把提议、讨论、合并一体化，是 GitHub 协作的核心。记牢三个动作：推分支、发 PR、等评审后合并。下一步学习代码评审（Code Review），学会在 PR 里给别人提意见、改自己代码。