如何在Git Rebase时避免重复解决他人已处理的合并冲突？

可能的原因 #

• 冲突标记残留：之前解决冲突时，没彻底清理<<<<<<<、=======、>>>>>>>这类冲突标记就提交了，导致Git后续rebase时仍判定这部分存在冲突。
• 公共分支历史被改写：如果dev分支有人执行了git rebase、git reset --hard这类修改历史的操作，你本地feature分支基于的旧dev提交在新的dev历史里已经不存在，Git重新对比时会重复触发冲突。
• 文件追踪误判：哪怕代码逻辑分离，若dev分支对相关文件做了重命名、移动（尤其是手动移动而非用git mv），或者在不区分大小写的系统上改了文件名大小写，Git的文件追踪机制会误判为内容冲突。
• 上下文关联触发冲突：有些看似分离的代码，可能在同一个文件的相邻区域有上下文依赖（比如同一配置文件的不同字段、同一类的不同方法），Git自动合并算法会因为上下文变化再次触发冲突，哪怕代码本身没有重叠。

解决办法 #

• 严格检查冲突提交：每次解决冲突后，用git diff确认代码无残留标记，再执行git add和git rebase --continue。也可以用git grep -n -E '<<<<<<<|=======|>>>>>>>'全局搜索项目里的冲突标记，一次性清理干净。
• 禁止公共分支改写历史：和团队约定，dev这类公共分支不允许执行历史改写操作。如果确实需要改写，提前通知所有人，你要先执行git fetch origin，再用git rebase --onto origin/dev <你本地feature分支基于的旧dev提交哈希>，重新基于新的dev历史构建你的feature分支。
• 规范文件操作：dev分支移动文件时必须用git mv，让Git正确记录文件关联；如果是文件名大小写问题，在区分大小写的系统上执行git config core.ignorecase false，确保Git能识别大小写变化。
• 开启冲突缓存功能：启用Git的rerere功能，它会记录你之前解决过的冲突方案，后续遇到相同冲突时自动应用。开启命令：

  git config --global rerere.enabled true
  

• 缩短同步周期：别等几周才同步dev，改成每周甚至每两三天同步一次。每次同步的变更越少，冲突概率越低，就算出现冲突也更容易处理，避免积累大量变更导致重复冲突。

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