Git Rebase后同事PR新增代码消失无冲突问题求助

这事儿我遇过好几次，本质是Git在rebase时的内容匹配逻辑搞的鬼，咱们一步步拆解：

先理清楚你的操作链 #

咱们把场景还原得更清晰点：

• 初始develop分支的foo.js是基准版本
• 同事在feature-a里给foo.js新增了100-120行（这里的行号是他分支里的，对应基准版本可能是插入到某个位置后生成的行号）
• 你在feature-b里基于初始develop，删除了foo.js的90-110行（这里的行号是你分支里的，对应基准版本的原始行）
• 同事把feature-a合并到develop，现在develop的foo.js已经包含他新增的100-120行
• 你执行git rebase develop，过程没冲突，但结果同事的新增代码没了

核心原因：Git是按内容匹配，不是行号 #

你以为删除的是“90-110行”，但Git眼里只认内容，不认行号。

当你在feature-b里提交删除操作时，Git记录的是「删除基准版本develop中90-110行的那段旧内容」。但同事合并后，develop里的foo.js已经变了：他新增的100-120行，刚好覆盖/移位到了你要删除的旧内容对应的位置（或者说，Git在匹配旧内容时，把同事的新增内容误判成了旧内容的一部分）。

这时候Git执行你的删除提交时，直接把它找到的“匹配旧内容的区域”删掉了——刚好就是同事新增的代码。而且因为你是删除、同事是新增，Git不认为这是“冲突”（冲突是两个提交修改了同一个内容，这里Git觉得你的删除是覆盖操作），所以全程没给你提示。

怎么解决？ #

1. 先找回丢失的代码

你可以通过git reflog救回来：

• 输入git reflog，找到你执行rebase之前的feature-b分支的提交哈希（比如开头是abc123那行）
• 执行git checkout abc123 -- foo.js，把rebase前的foo.js文件恢复出来
• 对比当前foo.js，把同事新增的100-120行补回去，然后重新提交

如果刚做完rebase，还可以直接用git reset --hard HEAD@{1}回到rebase前的状态，重来一次。

2. 重新rebase时避免踩坑

这次别直接无脑rebase了，用交互式rebase：

• 执行git rebase -i develop，会弹出一个编辑界面，列出你要“重播”的提交
• 把每个提交前面的pick改成edit，保存退出
• Git会逐个应用提交，每应用一个就停下来，这时候你赶紧打开foo.js检查内容：
  • 如果发现同事的代码被删了，就手动恢复，然后执行git add foo.js，再执行git rebase --continue
  • 直到所有提交都处理完

3. 以后怎么预防？

• 每次rebase/merge前，先跑git diff develop..feature-b看看你的分支和develop的差异，提前发现可能的内容重叠
• 别依赖行号判断修改位置，Git认内容不认行号，最好看修改的内容片段
• 如果不确定，改用git merge develop代替rebase——merge也可能出问题，但至少会把冲突摆到你面前让你处理，不会悄咪咪删代码

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