GitHub Desktop 如何创建 Pull Request：从当前分支到网页审核的完整路径

平时用GitHub Desktop提PR很多人刚上手容易点错按钮，最后搞反了合并的目标分支返工。整个流程的核心逻辑其实不复杂，先把当前分支的所有提交推到远程仓库，再选好要并入的目标base分支，点 Preview Pull Request 提前核对两边的代码差异，确认没有问题之后再跳转到GitHub网页补全说明走审核流程，就能避开不少“本地看没问题，到网页才发现比对错了分支”的麻烦。

最稳妥的顺序是：保存并提交修改 → 推送当前分支 → 预览差异 → 核对 base 分支和合并状态 → 创建 Pull Request。

先把本地分支整理到可提交状态

操作前先在 GitHub Desktop 顶部的仓库下拉栏确认你打开的是正确的项目仓库，再切到左侧的改动列表逐一核对。还没准备提交的文件先暂存或者移出改动区，在 Changes 面板里把所有待提交内容过一遍，确认都没问题之后，在下方的提交说明输入框写一句清晰的描述，点明这次改动要做什么，再点击 Commit to 当前分支 按钮完成本地提交。

Pull Request 面向的是给团队成员做代码审查用的完整、干净的改动集合，别把临时打日志的调试代码、自动生成的编译产物、明文的密钥配置这类内容一并提交进去。提交完成之后你能看到顶部仓库栏出现 Push origin 按钮，这就说明你刚做的本地提交还没同步到 GitHub 远程仓库。

推送完成后再进入预览入口

点击 Push origin 按钮等待上传同步完成。如果远程对应分支上有你本地没有的新提交，GitHub Desktop 会自动弹出提示让你先拉取新内容，这时候先点 Fetch 把远程最新的改动同步到本地，再重新核对当前分支的差异，别在远程状态不明的情况下直接发PR，很容易踩冲突的坑。

推送成功后，点击 Preview Pull Request。如果你非常确定当前分支的改动和目标分支都选对了，也可以直接点按钮旁边的下拉箭头，选择 Create Pull Request 直接跳转到GitHub网页发起PR；但第一次操作或者改动比较多的场景，更推荐走预览流程，界面会直接把两边代码的比对范围给你列出来，能提前发现分支选得不对的问题。

在预览窗口确认 base 分支

预览窗口打开后，先不要急着点创建。找到 base: 下拉框，确认它指向真正要接收改动的分支。默认分支可能是 main，团队开发也可能使用 develop 或发布分支，不能只凭默认值判断。

这个预览窗口同时会自动校验当前分支和目标base分支能不能自动合并。如果弹出无法自动合并的提示，先回到本地把代码冲突处理完，把远程最新的改动同步下来之后再重新走预览流程。能自动合并不等于代码逻辑没问题，这个状态仅仅代表Git的自动合并规则可以按现有内容完成文件层面的合并，不代表不需要做后续的人工校验。

跳转 GitHub 后填写审核信息

确认分支和差异后，点击 Create Pull Request，GitHub Desktop 会唤起默认浏览器直接跳转到对应的 GitHub 页面。这时候把标题和描述补写清楚：标题直接点明这次改动最终要实现的效果，正文部分写清楚改代码的原因、改动后要怎么验证、有没有需要审核者特别留意的边界场景。

如果你的改动还没开发完，暂时不想打扰别人审核，也可以点创建按钮的下拉选项，选择 Create Draft Pull Request 创建草稿PR。等所有逻辑都调试完准备正式走审核流程时，再到 GitHub 页面把草稿切换成正式状态，按团队流程提交就可以。

发布后用三个信号做验收

1. 网页上的源分支和 base 分支与 GitHub Desktop 预览窗口完全一致。
2. Files changed 或差异区域只包含本次提交涉及的文件，没有多余的无关改动。
3. 页面状态是正常待审核的 Pull Request，而不是仍停留在本地未推送或未转正的草稿状态。

如果跳转到网页之后看不到你刚提交的改动，先切回 GitHub Desktop 确认当前分支有没有真的执行过 Push origin；如果差异数量明显不对，优先检查 base 分支是不是选错了，有没有不小心跳到另一个项目仓库下发起请求。

常见问题：创建 Pull Request 时怎么判断已准备好

为什么看不到 Preview Pull Request？

通常是当前分支没有可供比对的正式提交，或本地所有提交还没有推送到 GitHub。先打开提交记录核对改动状态，再看顶部仓库栏的按钮提示，判断是漏了提交步骤还是漏了 Push origin 操作，对应补上即可。

能自动合并就可以直接合并吗？

不能。自动合并只描述文本和文件层面的合并条件，改动对应的测试结果、实际业务影响和代码逻辑层面的审查，仍然需要按团队流程逐一确认。

草稿 Pull Request 适合什么情况？

草稿 Pull Request 适合需要提前共享开发进度、但还不希望请求正式审核的半成品分支。描述中应明确标明当前未完成项，避免其他人把草稿误当成可合并的正式版本。

把一次创建流程固定成检查清单

日常实际操作时可以只记住这条短链路：Changes → Commit → Push origin → Preview Pull Request → base 分支核对 → Create Pull Request → GitHub 页面二次校验。每一步界面上都有明确的状态提示，遇到异常时也很容易定位是提交、同步、分支选择还是网页填写阶段出了问题。