rerere.enabled 必须手动开启，否则不工作；默认关闭，即使 git 版本为 2.54.0 或更新，也需执行 git config --global rerere.enabled true 才能启用自动记录与复用冲突解决方案。
rerere.enabled 必须手动开启，否则它完全不工作
Git rerere 默认是关闭的，哪怕你装的是 2.54.0 或更新版本，git rerere 命令能执行，也不代表它在后台自动记录或应用解决方案。必须显式启用：git config --global rerere.enabled true。如果只在某个仓库里用，去掉 --global，进到该仓库后运行 git config rerere.enabled true。
常见错误现象：反复在同一个 merge/rebase 中遇到相同冲突，但 Git 没有自动填充解决结果——大概率就是这个配置没开。顺带一提，rerere.autoupdate 可设为 true，这样 Git 会在你 git add 冲突文件时自动把当前解法存进数据库，省去后续手动 git rerere 的步骤。
rerere 记录的是“冲突块”而非整文件，所以重命名或移动文件会影响命中率
rerere 匹配冲突靠的是“上下文哈希”，即冲突发生位置前后的几行内容。只要这些行足够稳定，哪怕文件名变了、函数名改了，只要冲突区域的代码结构相似，它仍可能复用旧解法。
但以下情况会失效：
- 冲突块前后多于 3 行被改动（比如加了大段注释或空行）
- 文件被重命名后，rerere 仍按原路径记录，新路径无法匹配
- 同一文件中多个冲突块，只有部分被解决并
git add，rerere 只保存已标记为 resolved 的块
实操建议：对高频冲突文件（如路由配置、API schema），尽量保持其周边代码结构稳定；若必须重命名，可先 git rerere forget <old-path></old-path> 清除旧记录，再让新路径触发一次完整解决流程重新入库。
rebase 过程中 rerere 自动生效，但 merge 需要额外注意提交时机
在 git rebase 中，只要 rerere.enabled 开启，每次停在冲突处时，Git 会自动尝试应用已存的解法——如果匹配成功，连冲突标记都不会出现，直接进入 git add + git rebase --continue 流程。
而 git merge 场景下，rerere 同样生效，但有个关键细节：它只在合并提交真正生成前起作用。也就是说，你 git merge topic 触发冲突 → 手动解决 → git add → git commit 这整个链条里，rerere 只在第一次 git merge 命令执行时查库并预填；如果你中途 git merge --abort 又重试，它仍会查，但不会覆盖已有记录。
容易踩的坑：
- merge 后忘记
git commit，只git add，导致 rerere 记录的是“半解决状态”，下次可能误用 - 用
git checkout --ours或--theirs强制取某一方版本，rerere 会照单全收并存档——但这种“捷径解法”往往掩盖逻辑问题，后续再冲突时可能复用错误方案
gc.rerereUnresolved 和 gc.rerereResolved 控制记录寿命，老项目需定期清理
rerere 数据默认存在 .git/rr-cache/ 下，不随 push 上传，纯本地存储。它的生命周期受两个配置控制：gc.rerereUnresolved（默认 15 天）和 gc.rerereResolved（默认 60 天）。超过时限的记录会被 git rerere gc 清掉。
对长期维护的特性分支（比如开发周期 > 2 个月），可能出现“本该复用却没命中”的情况——不是配置错，而是旧解法被 GC 掉了。此时可临时调高阈值：
git config gc.rerereUnresolved 30git config gc.rerereResolved 180
但别长期留着过期记录：太多冗余条目会拖慢 rerere 查找速度，尤其当冲突块相似度高时，匹配耗时明显上升。建议每季度手动跑一次 git rerere gc，保持缓存精简。
