执行git rebase -i HEAD~N返回超N个提交，压缩提交频繁遇合并冲突如何解决

问题排查与解决方法 #

1. git rebase -i HEAD~2 提交数不符合预期的原因

这个问题是提交历史存在合并节点导致的：HEAD~n的计数逻辑是沿着当前提交的第一父提交路径向上追溯，遇到合并提交时不会统计其他分支路径上的提交，如果你最近的提交链路有分叉合并的情况，自然就会出现交互列表里的提交数和你预期的最近2条提交不符的情况。
这个问题和你squash时遇到的冲突确实存在关联。

2. squash反复出现冲突的原因

你要合并的提交如果分布在合并节点的不同分支路径上，默认的rebase操作会把合并提交拆解开，相当于把两条分叉路径上的提交按线性顺序重新应用，只要两个分支修改过同一个文件的同一位置，就会触发合并冲突。

适合入门用户的操作方案

• 如果你要合并的是自己做的、没有合并其他分支的线性提交，不要用HEAD~n的写法，先执行git log --oneline -n 10，手动找到你要合并的提交范围之前的那个提交的哈希值（取前6位即可，示例为abc123），改用git rebase -i abc123执行交互rebase，就能准确匹配你要操作的提交范围。
• 如果要合并的提交范围内包含合并节点，推荐用更简单的软重置方式实现合并，操作风险更低：
  • 先备份当前分支防止操作失误：git branch backup-before-squash
  • 执行软重置，重置到你要合并的n个提交之前的位置：git reset --soft HEAD~n（n替换为你要合并的提交数量）
  • 重新生成合并后的提交：git commit -m "你自定义的合并提交说明"
• 遇到冲突时的处理方法：打开标记了冲突的文件，找到<<<<<<<、=======、>>>>>>>包裹的冲突区域，手动编辑保留你需要的内容后删除所有冲突标记，执行git add 冲突的文件名，再执行git rebase --continue即可继续rebase流程；如果操作混乱可以随时执行git rebase --abort回退到rebase开始前的状态。

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