拉取请求是将代码更改合并到项目中的建议。 拉取请求是 GitHub 的核心 协作功能，让你能够在合并更改之前讨论并审查这些更改。 这有助于团队协同工作、提前捕获问题并维护代码质量。
查看拉取请求处理拉取请求
拉取请求将审阅者理解某项更改所需的上下文汇集到一起。 此上下文组织为选项卡：
- “ 对话 ”选项卡显示说明、时间线、批注和评论。
- 提交选项卡显示拉取请求分支随时间推移发生的变化。
- “ 检查 ”选项卡显示自动测试、生成和其他验证。
- 文件更改选项卡显示供审阅者了解拟议更改的差异内容。
- “结果”选项卡显示拟议更改的自动化代码审查结果，例如代码扫描警报。
除选项卡外，合并状态还会突出显示合并前的阻碍项、尚缺的批准及其他要求。 它会显示在拉取请求标题和合并框中。
这些视图共同帮助作者和审阅者讨论更改、跟踪反馈，并确定拉取请求何时准备好合并。
草稿拉取请求
创建拉取请求时，可以选择将其设为草稿拉取请求。 无法合并草稿拉取请求，并且不会自动请求代码所有者审阅它们。 如果要在不正式请求评审的情况下共享正在进行的工作，草稿非常有用。
准备获取对拉取请求的反馈时，可将拉取请求草稿标记为可供审查。 将拉取请求标记为可供审查将要求任何代码所有者进行审查。 可以随时将拉取请求转换为草稿。 请参阅“更改拉取请求的阶段”。
拉取请求引用和合并分支
当您打开拉取请求时，GitHub 会创建临时 Git 引用，使其指向该拉取请求的头部分支，并在可能的情况下指向模拟的合并结果。 这些参考可帮助 GitHub 和各项集成在不更改基础分支的情况下评估拉取请求。
对于大多数参与者，这些参考通常都处于后台。 当你构建自动化流程、调试 CI 行为或在本地获取拉取请求状态时，它们最为相关。 有关GitHub Actions使用合并分支的信息，请参阅触发工作流的事件。
比较页和拉取请求页上的提交之间的差异
比较页面和拉取请求页面可以基于不同的合并基点计算已更改的文件。 因此，相同的分支有时会在不同位置显示不同的差异。
这通常是在创建拉取请求后基分支发生更改时才会比较重要。 拉取请求页侧重于拉取请求引入的内容，而比较页面反映了两个 ref 之间的当前比较。
协作开发模型
使用拉取请求的方式取决于项目中使用的开发模型类型。 你可以使用复刻和拉取模型或共享仓库模型。
复刻和拉取模型
在分叉和拉取模型中，如果现有（“上游”）存储库具有读取访问权限，并且上游存储库的所有者允许该存储库，则任何人都可以为其创建分支。 请注意，分支及其上游共享相同的 Git 数据。 这意味着上传到复刻的所有内容都可从上游存储库及其所有其他复刻中访问。
不需要上游存储库的权限即可推送到创建的分支。 可以选择允许任何对上游存储库具有推送访问权限的人对拉取请求分支进行更改。 此模型非常适用于开源项目，因为它减少了新参与者的摩擦，并使用户无需预先协调即可独立工作。
提示
为深入了解开源，特别是如何创建和发展开源项目，我们创建了开源指南，它将帮助你培养一个健康发展的开源社区。还可以免费学习 GitHub Skills 课程来维护开源社区。
共享仓库模型
在共享存储库模型中，协作者对单个共享存储库具有推送访问权限，并在需要进行更改时创建主题分支。 拉取请求在这种模型中非常有用，因为它们会在将更改合并到主开发分支之前发起代码审查以及围绕这一组更改展开的一般性讨论。 此模型更常见于小型团队和组织在专用项目中协作。