如何merge/cherry-pick指定PR提交到master并保留完整提交历史

核心操作逻辑是通过普通提交拣选保留原始贡献者记录，再通过策略合并嫁接原始PR合并提交的元数据，全程不会引入不需要的W、X提交，也不会丢失任何贡献归属信息。 #

操作步骤 #

• 先同步本地仓库状态，切到主干分支并拉取最新代码

  git checkout master
  git pull origin master
  

• 按提交先后顺序，将bugfix分支上Alice提交的Y、Z两个普通提交拣选到master分支

  # 先拣选较早的Y提交，再拣选后续的Z提交
  git cherry-pick <Y提交的完整哈希值>
  git cherry-pick <Z提交的完整哈希值>
  

  注意：直接拣选普通非合并提交时，Git会完整保留原始提交的作者、邮箱、提交时间等所有元数据，GitHub贡献统计、git blame溯源都会正确识别提交归属为Alice，不会出现贡献记录丢失的问题。如果拣选过程出现冲突，正常解决冲突后执行git cherry-pick --continue即可，不会破坏元数据。

• 生成保留原始合并记录的合并提交，避开W、X提交引入
  执行以下命令，使用ours合并策略将原始PR合并提交M作为父节点嫁接，这一步不会引入W、X的任何代码变更，仅建立正确的提交拓扑关系：

  git merge -s ours --no-commit <原始M提交的完整哈希值>
  

  直接复用原始M提交的提交信息、作者（即执行PR合并操作的Bob）信息完成提交：

  git commit -C <原始M提交的完整哈希值>
  

• 验证提交链路符合预期后推送到远端
  执行以下命令查看提交拓扑，确认链路为A - B - C - D - Y - Z - 新合并提交，且没有W、X提交混入：

  git log --oneline --graph master
  

  确认无误后推送即可：

  git push origin master
  

方案有效性说明 #

• 不会引入W、X提交：整个操作没有将release分支作为合并源，W、X既不会出现在master的提交链路中，其对应的代码变更（如版本号升级）也不会被带入主干
• 完整保留所有贡献记录：Y、Z提交为直接拣选的原始普通提交，Alice的贡献归属完全保留；新生成的合并提交直接复用原始M提交的元数据，Bob的PR合并操作记录也完整留存
• 提交拓扑符合Git工作流规范：后续代码溯源、分支合并不会出现历史错乱问题，Git可以正确识别这组提交对应原PR的完整逻辑

原尝试方案的问题原因 #

• 直接git cherry-pick M失败：M是合并提交，默认拣选合并提交时仅会应用合并结果的单份差异，不会保留合并提交的双父节点拓扑，因此会丢失Y、Z的提交历史，且作者会被标记为执行拣选操作的人员
• 直接git merge release失败：release分支和master的共同祖先是提交A，Git会将A之后release分支上的所有提交（W、X、Y、Z、M）全部纳入合并范围，必然带入不需要的W、X提交

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