GitHub异步合并API正式可用：提交后凭请求编号查状态，自动化不能把受理当成完成

前天 3阅读

GitHub于2026年10月1日宣布异步合并API正式可用，可处理单个或堆叠PR，直接合并或加入合并队列。调用方先提交PUT请求，再使用返回的请求编号通过GET查询状态。官方将它列为程序化合并的推荐路径；规则绕过仍要求调用者具备相应权限。

一个请求分成两段，记录也要跟着改变

以下为本文的接入分析。同步接口常让调用方习惯于等待一个最终回答；异步流程则先说明工作已被接收，再在之后给出结果。如果自动化在拿到请求编号时就向团队报告“已合并”，状态就走在事实前面。用户需要知道的是请求已提交、仍在处理，还是合并确实完成。

一种清楚的内部记录可以同时保留仓库、PR编号、预期目标分支、提交时间和服务返回的请求编号。后续查询、超时处理和人工排查都围绕同一条记录展开。这样即使执行脚本重启，接手的人也能找到正在进行的工作，而不是凭一行旧日志猜测。

AI模型生成的概念示意图，以分支汇合和独立状态标记表现异步处理，并非GitHub截图或实际运行结果。

堆叠PR通常把一项较大的变更拆成有先后关系的几份修改。官方公告称，新接口是目前支持堆叠PR的合并API。对团队而言，接口能接收这种结构只是起点，评审内容、基础分支和预期顺序仍应保持一致。

例如第一份PR建立数据结构，第二份增加使用它的功能，第三份更新文档。自动化记录应能让维护者看清本次提交覆盖了哪几层；一旦其中某层发生修改，不能只因为最末一份此前通过检查，就推断整组仍然满足条件。具体可合并性由平台当前状态和项目规则共同决定。

合并队列也有自己的等待过程。加入队列意味着进入后续安排，不能把队列入口和代码进入目标分支写成同一个时间点。需要统计交付耗时的团队，最好分别记录提交请求、进入队列与最终完成，才有办法解释等待发生在哪里。

网络响应丢失时，最需要避免的是把“本地没有收到结果”直接解释为“远端什么也没做”。若已经拿到请求编号，应沿原编号继续检查；如果编号也未收到，就结合PR当前状态、平台记录和接口文档决定恢复办法。本文没有假定接口具备公告未说明的自动去重保证。

可以用测试仓库验证几种过程：正常完成、仍在等待、规则不满足，以及查询暂时失败。观察每种情况是否留下清楚状态，并让后续发布或通知步骤只在对应条件满足后启动。异步接口减少单次请求承载的等待，却把持续追踪结果的责任交给了调用流程。

迁移也可以按一条自动化逐步进行。先确认负责人能看懂状态记录，再扩大到更多仓库，往往比一次替换全部调用更容易发现旧脚本中隐含的同步假设。

GitHub异步合并API官方公告发布于2026年10月1日，本文于北京时间2026年10月2日核验。接入建议与示例为原创分析，本站未实际测试接口。