同一类冲突反复出现在 rebase 或合并里时，可以让 Git 记录已经确认过的解决方式，后面自动复用。
环境：Git 2.20+。先在当前仓库开启：
git config rerere.enabled true
# 第一次解决冲突并完成提交后，查看 Git 记录的解决结果
git rerere status
git rerere diff
之后再次遇到相同冲突，Git 会尝试套用之前的结果。应用后不要直接无脑提交，先检查工作区和测试：
git diff
git status
# 按项目实际命令运行测试
确认没问题再 git add 和继续 rebase。想清掉某个已经不合适的记录，可以用 git rerere forget -- <path>；整个仓库的记录通常在 .git/rr-cache/，不建议把它当成代码提交进仓库。
补一个容易踩的点：自动套用成功后，默认也别急着当成已经暂存。可以先看 git diff 和 git status，确认无误后再 git add。如果团队对这套冲突结果很有把握，也可以单独评估 rerere.autoupdate，让 Git 自动把已应用的结果加入暂存区；公共仓库或复杂重构场景我会更倾向保持默认，手动复核更稳。
再补个边界：rerere 记的是冲突上下文对应的解决结果，不是“这个文件永远这么改”。代码大幅重排、依赖版本变化后，即使自动套上了，也要把它当候选结果重新看一遍。长期积累的缓存还可以偶尔用 git rerere gc 清理，避免旧记录越来越多。
还有个配置范围的小细节：只想让它影响当前仓库时，可以显式写成 git config --local rerere.enabled true；不建议在 CI 里随意把 runner 的 .git/rr-cache 当成长期共享缓存，分支和代码上下文变化后，旧结果可能反而增加复核成本。个人本地开着通常更合适。