Git怎么创建Pull Request_Git提交PR合并请求流程详解【实战】

Pull Request（PR）是代码托管平台基于Git分支实现的协作流程，非Git原生命令；需推送非默认分支至有写权限的仓库后，GitHub才显示PR按钮，或用gh CLI工具创建。

先说一个核心概念：你在GitHub上看到的Pull Request（PR），其实并非Git的原生功能。 它是GitHub、GitLab这类代码托管平台，巧妙地基于Git的分支机制，包装出来的一套协作流程。所以，别指望在本地敲个git命令就能“创建PR”——这事儿必须通过平台的Web界面，或者它们提供的命令行工具（比如GitHub的gh）来触发。

为什么 git push 后没看到 PR 按钮？

很多新手会有一个错觉：代码推上去，PR按钮就应该自动冒出来。其实不然，推送代码和发起PR是两个独立的操作。GitHub的机制是：只有当你向一个你有写权限的仓库，推送了一个非默认分支（比如feature/login）之后，它才会在仓库主页顶部友好地弹出一个绿色的“Compare & pull request”按钮。

这里的关键在于“权限”和“分支”。具体来说，分几种情况：

• 最常见的情况：你Fork了仓库。 比如，你把别人的项目owner/repo fork成了yourname/repo。这时，你得先把代码git push到你自己的这个fork仓库里，然后从fork的页面发起PR，目标是上游（upstream）的原仓库。
• 你有协作权限。 如果你直接克隆的是主仓库（git clone https://github.com/owner/repo.git），并且对方给了你collaborator权限，那么你推送新分支后，按钮就会在原仓库页面出现。
• 检查远程跟踪。 推送前，最好用git status或git branch -v确认一下当前分支是否已经正确关联（track）了远程分支。可以用git branch -u origin/feature/x来建立关联，否则git push可能会失败，或者推到意想不到的地方。

用 gh CLI 快速提交 PR（免网页操作）

如果你厌倦了在浏览器里点来点去，GitHub官方命令行工具gh绝对是效率利器。它能让你在终端里一条命令就搞定PR创建，全程无需打开网页。当然，前提是你已经用gh auth login登录好了，并且本地分支已经推送到远程。

操作流程很清晰：

• 配置远程仓库。 如果你是通过Fork参与的项目，记得添加上游仓库地址：git remote add upstream https://github.com/owner/repo.git。
• 推送分支。 执行git push -u origin feature-auth，把本地分支推上去。
• 创建PR。 核心命令来了：gh pr create --title “Add JWT validation” --body “Fixes #123” --base main --head feature-auth。

这里有几个参数需要注意：--base指定的是你想合并到的目标分支（通常是main或develop），--head则是你当前的功能分支。如果省略--head，gh工具会默认使用你当前所在的本地分支。

PR 描述里写什么才不被拒？

PR描述是你的“敲门砖”，维护者往往扫一眼就决定要不要深入看代码。空着不写、只写一句“fix bug”、或者贴上一大段日志，基本都会被要求重写，甚至直接关闭。

那么，一份合格的PR描述应该包含什么？

• 标题要清晰。 第一行标题必须用明确的动词开头，比如Add、Fix、Refactor。尽量避免使用Update、Change这类模糊的词汇。
• 正文讲清三点。 正文里至少需要涵盖：What（这次修改具体做了什么）、Why（为什么要做这个修改，最好关联上Issue编号，例如Resolves #45）、How（关键的设计思路或实现方式，不必贴全部代码细节）。
• 慎贴代码差异。 不要把git diff的输出直接粘贴进去。如果需要展示效果，附上截图或者简短的curl命令示例会更有效，但也仅在必要时提供。
• 说明变更影响。 如果这次修改涉及数据库迁移、API接口变动等破坏性更新，必须单独设立一个小节，明确说明迁移步骤、回滚方案以及对兼容性的影响。

最后必须提醒的是，提交PR远不是终点，而是协作的真正起点。最容易踩的坑包括：没有检查CI（持续集成）是否全部通过、忘了更新相关的文档、以及在多人协作的仓库中没有同步最新代码（记得git fetch upstream && git rebase upstream/main）。这些环节一旦出问题，会让代码审查过程卡住，耗费的时间可能比写代码本身还要多。