GitHub PR合并成功但merge_commit_sha为空的原因及解决办法

原因分析 #

出现这种情况的核心原因是PR合并时没有生成常规的合并提交（merge commit），具体分为以下两种场景：

• 快进合并（Fast-forward merge）：当目标分支（如master）的提交历史完全是feature分支的前缀时，GitHub会默认采用快进合并——直接将目标分支的指针移动到feature分支的头部，不会生成新的merge commit。此时Web界面显示的"三个SHA"本质是feature分支头部、原master头部，以及当前master的头部（与feature头部一致），并没有独立的merge commit，因此API返回的merge_commit_sha为null。
• 选择了Squash/Rebase合并方式：如果合并PR时手动选择了「Squash and merge」或「Rebase and merge」，同样不会生成带有双父节点的merge commit：
  • Squash合并会将feature分支的所有提交压缩为一个新提交，直接追加到目标分支；
  • Rebase合并会将feature分支的提交重新应用到目标分支的最新头部，最终目标分支的提交历史是线性的，没有merge commit。

只有当选择「Create a merge commit」的合并方式时，才会生成带有两个父节点的merge commit，此时API的merge_commit_sha字段才会被正确赋值。

解决办法 #

方案1：强制生成merge commit（推荐，适配现有CI依赖） #

通过设置确保PR合并时必须生成merge commit：

• 仓库全局配置：进入仓库的「Settings」→「Branches」→「Branch protection rules」，找到目标分支（如master）：
  1. 勾选「Require a pull request before merging」；
  2. 在「Merge options」中，取消勾选「Allow squash merging」和「Allow rebase merging」，仅保留「Allow merge commits」。
     这样所有PR合并都会强制生成merge commit，API返回的merge_commit_sha会被正确设置。
• 单PR手动选择：合并单个PR时，在Web界面的合并选项中，明确选择「Create a merge commit」选项，而非其他两种合并方式。

方案2：调整CI逻辑（适配非merge commit的合并场景） #

如果必须使用Squash或Rebase合并方式，可修改CI流程依赖的字段：

• 改用PR的head.sha：通过API获取PR对象的head.sha字段，该值是feature分支的最后一个提交SHA；
• 改用目标分支的最新SHA：调用API查询目标分支（如master）的最新提交SHA，以此作为CI触发的依据。

内容的提问来源于stack exchange，提问作者StaticMethod