Git合并PR时覆盖历史提交且无痕迹，原因是什么？

问题根源 #

这种情况核心原因是成员B创建分支时没有基于最新的main分支拉取代码：

• 成员A合并PR后，main分支里目标文件的第45行已经改为63；
• 成员B的分支基于A修改前的旧版本创建，本地文件第45行仍为6；
• 当B在该行上方新增内容并合并PR时，GitHub自动合并会将B的修改（新增行+旧的第45行内容）覆盖到main分支，但因为B的提交没有显式的撤销操作，提交历史只会显示A的修改记录和B的新增行记录，看不到覆盖痕迹。

修复步骤 #

1. 验证问题
   在本地仓库执行命令查看文件的提交差异：

   git log --oneline -p 目标文件名
   

   查看成员B的提交内容，会发现他的提交里第45行本来就是6，证明他的分支从未同步过A的修改。

2. 恢复A的修改

   • 方案一：直接修改恢复
     打开目标文件，将第45行改回63，提交时备注：恢复[A的提交哈希]中对XX文件第45行的修改（A的提交哈希可从提交历史中复制），随后推送到main分支。
   • 方案二：用Git命令重放修改
     执行以下命令，将A的修改重新应用到main分支：

     git checkout main
     git pull origin main
     git cherry-pick <A的提交哈希>
     

     若出现冲突，手动解决后提交即可。

3. 预防措施

   • 要求所有成员在创建新分支前，必须通过GitHub Desktop的「拉取 origin」功能同步最新的main分支代码；
   • 合并PR前，先在PR页面点击「更新分支」，让PR分支同步最新的main代码，解决冲突后再合并；
   • 在仓库设置中开启「要求拉取请求在合并前必须是最新的」，强制PR分支与main同步后才能合并。

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