GitHub PR恢复后怎样核对源分支提交和CI检查状态

GitHub拉取请求在故障恢复后仍显示旧提交或检查未结束时，可以分别读取PR的源分支提交和CI检查状态。提交同步与检查结果是两组证据，不能用“页面能打开”替代，也不能把所有pending都认定为漏触发。

先读取PR当前指向的源分支提交

适用环境是已安装并认证的GitHub CLI终端，账号需要具有目标仓库和PR的读取权限。下列OWNER/REPO替换为仓库名，PR_NUMBER替换为真实PR编号；示例不会修改分支或PR，也没有对任何用户仓库做实际测试。

gh pr view PR_NUMBER --repo OWNER/REPO --json number,state,headRefName,headRefOid,baseRefName,updatedAt

预期得到PR对象，headRefOid是源分支提交标识，headRefName与baseRefName分别说明源分支和目标分支。这个读数可以帮助识别正在检查的是哪个PR，但updatedAt并不是所有后台处理完成时间，也不是Actions运行成功时间。

再查看这一个PR的CI检查

保持同一仓库和PR编号，读取检查名称、状态、分类及详情地址；不加--required以免一开始只看到必需检查而漏掉其他检查。

gh pr checks PR_NUMBER --repo OWNER/REPO --json name,state,bucket,workflow,event,link

预期得到检查列表。bucket将检查归为pass、fail、pending、skipping或cancel，便于理解不同状态；pending说明检查尚未完成，不能当成明确失败。此命令对等待中的检查还可能返回退出码8，自动化脚本不能把每个非零退出码都粗暴解释为“没有CI”。

为什么提交标识和检查名称都需要保留

同一PR可以经历多次推送，检查名称也可能重复出现。把源分支SHA、检查详情和具体工作流对应起来，比只看“绿色数量”更能说明当前结果。PR检查汇总不是所有历史运行清单，检查链接存在也不代表它一定属于预期的最新提交。

某个检查未出现还可能与仓库配置的事件、分支及路径条件相关。上面两条命令提供的是当前可读取信息，不会自动判断仓库触发规则是否正确；权限或网络报错也应与正常空结果区分。

复盘说明了哪些残留现象

11月10日约15:00至17:55 UTC，GitHub仓库页面、PR及Actions出现性能下降。总体服务下降结束后，部分PR仍显示源分支较早提交，后台处理继续追赶积压。官方同时披露约1.8%的事件出现Actions延迟，另约0.09%的PR事件没有启动工作流，需要重新触发。

根因是共享Git基础设施过载，近期变更增加了后台分析及合并计算的工作量。关闭一项合并处理优化、暂停后台分析和临时限制低优先级流量后服务缓解。后续改进包括减少重复分析、加入工作负载级并发控制和加强PR同步韧性。

这些信息解释了为何同步、运行启动和最终检查结论可能先后恢复，却没有证明某个具体PR必须重跑。先取得PR及检查证据，再决定后续处理，可以避免把原本仍在推进的任务重复启动。