rerere是唯一靠谱的解法，因git默认不记忆冲突解决过程，而rerere通过记录并复用相同冲突块的解决操作（同一文件、相同行范围、相同内容差异）实现自动应用，但仅限行级文本冲突，不适用于目录结构冲突。
为什么 rerere 是唯一靠谱的解法
Git 默认对重复冲突完全无感——哪怕你上周刚手动解决过同一处冲突，下周合并时它照样把 和 <code>>>>>>> feature 标记塞进文件里。这不是 bug，是设计：Git 不记录“人怎么想”，只记录“人做了什么”。rerere（Reuse Recorded Resolution）是唯一能打破这个循环的内置机制，它不改 Git 的哲学，只是悄悄在背后记下你每次删哪行、留哪行、怎么改的 diff 行为。
启用 rerere 并确认它真在工作
执行 git config --global rerere.enabled true 后，别以为万事大吉。它默认只在你真正触发冲突并手动解决后才开始记录。验证是否生效：
- 运行
git rerere status—— 初次启用时应为空；解决一次冲突后，这里会列出已缓存的冲突路径 - 检查项目根目录下是否存在
.git/rr-cache/目录，里面每个子目录对应一个冲突文件的 hash，内容是原始冲突块和你最终选中的解决结果 - 下次遇到相同冲突时，
git merge输出里会出现Resolved 'path/to/file' using previous resolution.这才是 rerere 在干活
rerere 的边界在哪：哪些冲突它救不了
rerere 只匹配“完全相同的冲突上下文”：同一文件、完全相同的冲突起始行和结束行、完全相同的两段差异内容。只要其中任意一项有毫厘之差，它就放弃自动解决。常见失效场景：
- 两个分支都改了同一函数，但 A 分支改了第 5 行，B 分支改了第 6 行 → 上下文偏移，rerere 不触发
- 冲突块里有一行空格或注释被增删 → 内容 hash 变，匹配失败
- 你上次解决时手抖多删了一行，这次 rerere 照搬错误 → 它不判断逻辑对错，只复刻操作
- 用 IDE 的“接受左侧”一键解决，但没走
git add+git commit流程 → rerere 没机会记录
配合 git merge --no-commit 避免误提交
即使 rerere 自动解决了 80% 的冲突，剩下那 20% 仍可能藏雷。直接 git merge feature 会立刻提交，出错就得 git merge --abort 回退。更稳妥的做法是：
- 先跑
git merge --no-commit feature—— 合并完成但不自动生成提交 - 用
git status看哪些文件被 rerere 自动解决（状态为modified），哪些仍标unmerged - 人工检查所有
modified文件，确认 rerere 的结果没引入逻辑矛盾（比如它保留了 A 分支的缓存逻辑，却删掉了 B 分支的异常处理） - 全部确认无误后，再
git commit -m "merge feature with rerere"
rerere 的价值不在“全自动”，而在把重复劳动压缩到最小——它省掉的是机械性编辑，不是思考过程。真正危险的永远是语义冲突，而那个部分，至今没人写得出能替代人脑的工具。
