github合并pull request时超时，不能只凭这个提示认定合并失败。超时表示调用方未及时取得预期响应，具体pr是否已经合并仍是另一个结果。2026年11月13日的这起pull requests事件曾造成部分合并尝试超时，github已于北京时间11月14日02:29将事故标记为已解决。
超时提示没有回答哪些问题
超时本身没有确认目标分支是否已变化，也没有确认某个PR的最终状态。把它直接转换成“没有发生合并”，会混淆请求返回与业务结果；反过来，没有看到明确失败也不能当作成功。
尤其在多人共同维护仓库时，同一PR还可能由其他有权限的协作者处理。决定下一步行为所依赖的应是这个PR的实际状态，而不是把一个较早的错误提示当成持续有效的结论。
这次事故实际确认了什么
北京时间11月13日23:47，GitHub报告Pull Requests可用性降级；23:49进一步明确，部分合并尝试出现超时。官方将影响限定在这条路径，没有在初始说明中宣布所有Git操作、所有Actions工作流或全部GitHub服务不可用。
后续缓解说明披露，问题起初影响约3%的请求，之后降至不足1%；另一次进展又报告约1%的合并请求仍超时。这些是不同时间的观测，不能拿其中一个比例推算全天受影响PR总数，也不能简单相加。
为什么不应无条件重复提交合并
重复发起动作并不能弥补对已有结果的不了解。如果原操作已经完成，再把旧提示当成未完成依据，会让自动化记录与仓库状态发生偏差。更稳妥的判断顺序是先区分“结果仍未知”和“已经明确未合并”，再决定是否还需要新的操作。
这不是一条适用于所有仓库的固定重试次数或间隔规则。GitHub没有为这次事故提供统一的客户端重试参数，也没有要求关闭分支保护、忽略检查或扩大账户权限来解决上游异常。
事故解决后还需要区分什么
服务恢复是平台层面的结论，具体PR结果是业务层面的结论。GitHub先将降级标记为已缓解并监控，随后于北京时间11月14日02:29宣布事故已解决；这并不逐条证明故障期间每个合并任务都已按照调用方预期完成。
同样，PR合并结果与下游构建、测试或部署结果也不是同一个状态。这起事故的公开说明没有声称所有下游自动化都需要重跑，因此不能因为出现过合并超时，就批量重跑全部工作流。
现在能否认定根因已经公开
尚不能。解决通知承诺后续分享详细根因分析，但这一条通知本身没有给出完整原因。11月10日另一场Git与PR事故的复盘、上游邮件故障或其他服务的异常，都不能直接套用为这次合并超时的确定根因。
