GitHub Desktop 创建 Pull Request 怎么验收：分支差异、Checks 与合并前核对

用 GitHub Desktop 提交 Pull Request 时，最容易被忽略的卡点从来不是点不点创建按钮，而是分支比对对象和远端验收状态没捋顺：当前功能分支可能还没推到远程仓库，差异列表里可能混进不该提交的本地文件，自动检查任务也可能还没跑完。比较稳妥的操作流程是先在 Current Branch 面板确认当前分支身份，再核对 Changes 改动列表和 Preview Pull Request 预览页，推送完成后回到当前分支同步查看 Checks 状态，确认所有项无误后再把 PR 发给团队评审。

先把 GitHub Desktop 的验收目标定清楚

这套操作流程适合已经创建好功能分支、准备把改动送入 main 或 develop 的场景。下面示例使用 feature/order-filter 作为工作分支，目标合并分支是 main。你可以替换成自己仓库对应的分支名，但要守住三个核心核对点：

• 所有改动都仅来自当前功能分支，没有混入其他分支的多余提交；
• PR 的 base branch 确实是本次改动正式要合入的目标分支；
• 远程仓库的 Checks 任务已经跑完，给出清晰的通过或失败结果。

在 Current Branch 中确认比较分支和改动边界

打开本地仓库后，先看界面顶部的 Current Branch 选项，如果当前选中的分支不是 feature/order-filter，先切换到对应分支；如果工作区还有未提交的改动，先在 Changes 面板逐份文件查看 diff 内容。尤其注意本地调试日志、临时配置文件和编译生成的文件夹，这类内容很容易在没察觉的情况下混进 PR 改动列表。

确认改动文件范围没问题后，再核对当前分支相对目标分支的提交关系。选择比较分支时优先选团队提前约定好的目标分支，不要因为下拉列表的第一项是 main 就直接默认确认。可以参考下面的表格做简单记录核对：

用 Preview Pull Request 看一遍标题、描述和差异

确认分支信息无误后，在 GitHub Desktop 的提交区域填写准确的提交说明，然后点击 Preview Pull Request 按钮。预览页面重点核对三处内容：

1. 目标仓库和目标分支：确认没有选到个人 fork 仓库或者已经废弃的旧发布分支。
2. Files changed：改动文件数量和 diff 内容要和本次功能需求匹配，不该出现全文件内容重排或者完全无关的目录。
3. 标题与描述：标题直接说明改动最终效果，描述里补充验证方式和已知的边界情况，不要直接复制提交摘要当 PR 说明。

这个预览步骤是很有价值的停顿校验点，如果发现差异范围明显超出预期，先返回 Changes 面板调整工作区内容；如果只是提交说明信息不准确，改完说明之后再预览一次。不要为了让文件列表看起来更短就随意丢弃改动，先确认这些待提交内容确实属于当前开发任务。

Push origin 后检查远端状态是否接上

正式创建 PR 之前，GitHub Desktop 一般会提示先把当前本地分支推送到远程仓库。点击 Push origin 按钮后，等仓库侧边栏状态回到稳定，再确认远程分支的名称和本地分支完全一致。第一次推送完成后如果界面还在显示 Push origin 按钮，先检查网络连接和当前仓库的写入权限，不要连续重复点击推送。

PR 创建完成后，Current Branch 区域附近会显示分支和 PR 的关联状态。如果仓库提前配置了自动检查任务，状态一开始会显示等待中，之后才刷新为通过或者失败。等待中的状态既不算成功也不算失败，只代表所有检查任务还没运行完成。

在 Checks 面板完成合并前验收

打开关联的 Pull Request 页面，查看 Checks 区域的运行结果。如果所有检查都通过，至少核对检查任务名称、触发对应的提交版本和完成时间，确认这些记录都对应刚才推送的最新提交。如果检查失败，先点进失败的任务项读取具体运行日志，再判断是代码本身有问题、测试环境异常，还是本地分支没有同步目标分支的最新内容。

如果对应检查任务支持手动重新运行，可以在修正完问题之后再触发重试；但重新运行之前要确认本地工作区和远程仓库的提交内容已经完全同步。最后可以用下面的清单做最终交接核对：

• 当前分支：功能分支名称和开发任务对应无误；
• 目标分支：base branch 符合团队仓库约定；
• 差异范围：没有混入临时文件、调试日志和意外生成的文件夹；
• 远端同步：Push origin 推送完成，PR 指向最新的提交版本；
• 检查结果：Checks 全部通过，或者失败的原因已经明确写在 PR 描述里同步给评审人。

常见问题：三个最容易误判的界面状态

为什么 Preview Pull Request 看不到预期改动？

先检查当前选中的分支是否切错，再确认对比分支是不是刚刚更新过内容的目标分支。如果相关提交已经被提交到其他分支上，GitHub Desktop 不会自动把这些提交纳入当前 PR 的改动范围里。

Push origin 后为什么还没有 Checks 记录？

检查任务一般由远程仓库的推送事件触发，推送完成后可能需要几秒到十几秒的等待时间。先打开 GitHub 网页端的 PR 页面确认工作流有没有被正常触发；如果完全没有任何任务记录，再去核对仓库的 Actions 配置或者分支保护规则。

Checks 失败能不能直接重新运行？

可以，但最好先读完失败日志，确认代码或者环境问题已经被修正之后再操作。没有做任何改动就反复重试检查，只会把真正存在的问题延后到后续流程里才暴露。

把一次 PR 验收结果留在描述里

GitHub Desktop 可以快速完成分支切换、提交和推送操作，但最终的代码评审还是要依托 PR 页面里的差异内容、Checks 结果和评论讨论区。建议在 PR 描述末尾补充简单的验收记录：本次改动做了什么、本地跑过哪些验证命令、Checks 最终结果是什么、还有哪些边界场景没有覆盖到。这样后续评审的同事不需要反复核对信息去猜，就能知道这次提交已经验收到了哪一步。