PR合并后提交哈希变更的原因及Commit SHA追踪方法

场景说明 #

我正在实现代码完成以下操作：

• 检查upstream/main中大量已合并的Pull Request（PR）
• 满足特定条件时，将PR中的提交cherry-pick到本地分支

过程中发现GitHub上PR的提交哈希合并到main分支后有时会变化，现针对以下两个问题寻求解答：

1. 这种情况为何会发生？
2. 在此情况下如何追踪对应的Commit SHA？

附：git log --decorate --graph --oneline upstream/main输出 #

* 862c7e2ee
* 2e33b0547
* 7bec340d9
* 951748c89
* 7076c050d
*   a31f0e164 
|\
| * 29161b2fd 
* | 5a80cb389 
* | a7217055c 
* | 568518b6a 
* | 7e4d4d652
* | 4be3c3e7f
* | f5c92ca2d 
* | 0f0eb7c2b 
|/
*   f93a4c877 
|\
| * 36415a25f 
| * 15d59cbf2
* | 98c982d91
* |   bcc89944f
|\ \
| * | ec83f920d
* | |   19cc2e4d4
|\ \ \
| * | | 0cb401a8c
* | | |   6fc65bbe4
|\ \ \ \
| |_|_|/
|/| | |

一、提交哈希变化的原因 #

Git提交哈希是基于提交的完整内容计算的，包括：

• 提交的父节点
• 提交时间戳
• 作者/提交者信息
• 提交消息
• 文件内容快照（树对象哈希）

当PR合并到main时，以下几种合并方式会导致哈希变化：

• 非快进合并（默认合并方式）：会生成新的合并提交（如你log中的a31f0e164），PR原始提交哈希不变，但如果合并时处理了冲突，冲突解决后的提交哈希会改变。
• Squash合并：GitHub将PR中所有提交压缩为一个新提交，原始提交不会进入main历史，新提交哈希与原始提交完全不同。
• Rebase合并：将PR提交重新应用到main最新提交之后，这会修改每个提交的父节点和时间戳，导致所有PR提交哈希全部改变，原始提交不会出现在main历史中。

从你提供的git log来看，仓库主要使用非快进合并（存在大量合并节点），但如果部分PR用了squash或rebase合并，就会出现哈希不匹配的情况。

二、追踪对应Commit SHA的方法 #

1. 利用GitHub PR元数据 #

GitHub为每个PR维护特殊引用，直接关联原始提交和合并结果：

• 查询PR原始提交：git show refs/pull/<PR编号>/head
• 查询PR合并后的提交（非快进合并）：git show refs/pull/<PR编号>/merge
• 若为squash合并，GitHub会在新提交消息中自动添加(#<PR编号>)，可通过消息搜索：

  git log --grep="(#<PR编号>)" upstream/main
  

2. 通过Git历史回溯 #

针对非快进合并的PR：

• 找到log中的合并提交（如a31f0e164），查看其两个父节点，其中一个即为PR分支的最后提交：

  git show --pretty=raw a31f0e164
  

  输出中的parent字段会列出两个父节点，对应PR分支和main分支的合并前状态。

针对rebase合并的PR：

• 用git cherry对比PR原始分支与main分支，找出被重写的提交：

  git cherry upstream/main refs/pull/<PR编号>/head
  

  输出中-开头的条目即为被rebase后哈希变化的提交。

3. 通过提交内容匹配 #

如果以上方法失效，可直接对比提交内容：

• 查看PR原始提交的diff：git show <PR原始哈希> --patch
• 在main分支中搜索包含相同diff的提交：

  git log --patch upstream/main | grep -A 20 -B 5 "<diff中的唯一特征行>"
  

• 验证两个提交内容是否一致：

  git diff <PR原始哈希> <main分支可疑哈希> --stat
  

  若输出为空，说明两个提交内容完全一致，仅哈希不同。

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