Git rerere 怎样复用重复冲突的解决结果

如果一个长期维护的分支会反复合并上游，同一片代码冲突往往要被手工处理多次。Git rerere 的作用就是把第一次确认过的冲突解决结果记录下来，下一次遇到相同或足够接近的冲突时尝试复用。它能减少重复编辑，但不会替你完成最后验收：自动应用后仍要检查差异，并明确执行 git add。

官方地址：https://git-scm.com/docs/git-rerere

最稳妥的使用方式是：先开启 rerere，第一次冲突人工解决并检查；后续复用时继续看 git diff 和未解决路径，确认正确后再暂存、提交。

一、先开启 rerere，让 Git 记住第一次解法

rerere 默认需要通过配置启用。建议先在目标仓库设置，而不是一开始就改全局配置，这样可以把记录范围限制在确实需要长期合并的项目里。

# 在当前仓库开启冲突解决记录与复用
git config rerere.enabled true

# 读取当前仓库的配置，确认开关已经生效
git config --get rerere.enabled

之后执行一次正常的合并或变基。遇到冲突时，可以先查看哪些文件仍需要人工处理，再查看当前解决内容的差异。

# 发起示例合并；分支名替换为你的真实目标分支
git merge release

# 查看 rerere 正准备记录的冲突路径
git rerere status

# 查看尚未被自动解决的路径
git rerere remaining

# 查看当前冲突文件的解决差异，便于人工检查
git rerere diff

第一次解决时，直接编辑冲突文件，删除冲突标记并保留正确内容。确认无误后再加入暂存区并提交：

# 查看完整工作树差异，确认没有误删或误合并
git diff

# 只暂存已经人工确认过的冲突文件
git add path/to/file

# 创建合并提交，让 Git 记录这次已经确认的解法
git commit

二、再次冲突时，先验收复用结果再提交

当上游和主题分支再次改动相同区域时，Git 会尝试调用已经记录的解决方案。复用成功不等于可以跳过检查，因为当前文件可能已经带入了新的上下文，旧解法未必仍然适合。

# 再次合并上游，观察是否出现相同类型的冲突
git merge release

# 查看仍然没有自动解决的路径
git rerere remaining

# 对照工作树差异，核对自动复用后的真实内容
git diff

如果 remaining 仍然列出文件，就把它当作普通冲突继续人工编辑；如果没有剩余路径，也要重点检查关键业务分支、边界条件和被移动的代码。rerere 只负责写入工作树，索引不会替你完成最终确认，因此验收后仍要 git add，再由测试或代码审查继续把关。

# 再次确认自动复用后的完整差异
git diff

# 将复查通过的文件加入索引
git add path/to/file

# 在测试和审查通过后完成本次合并提交
git commit

三、哪些情况不要盲信自动复用

同一文件的代码语义已经改变、冲突区域发生重构，或者历史解法本身曾经被误提交时，都不适合直接接受结果。可以把 git rerere diff 当成复查入口，并把关键测试放在合并提交之前。

还要注意，rerere 依赖文件中的冲突标记来识别冲突。如果文件内容本身包含容易混淆的标记样式，记录可能无法按预期工作。对于二进制文件、子模块等不能按普通文本方式追踪的对象，也应按 Git 的实际提示单独处理。

四、错误记录怎样清理

如果某次解决方案已经过时，不要继续让它自动套用。按影响范围选择命令：

# 只忘记当前冲突路径的历史解决方案
git rerere forget -- path/to/file

# 合并或变基已经放弃时，清除对应的 rerere 元数据
git rerere clear

# 清理长期未使用的冲突记录，控制 .git/rr-cache 的增长
git rerere gc

forget 更适合局部纠错，clear 用于中止当前冲突后的元数据清理，gc 则是周期性的过期记录整理。清理后第一次再次遇到该冲突，需要重新人工解决并检查。

常见问题

开启 rerere 后为什么仍要 git add？

因为 rerere 可以把复用结果写回工作树，但不会替你更新索引。检查 git diff 确认内容正确后，仍需显式暂存。

rerere 自动解决了冲突，是否可以直接提交？

不建议。至少查看差异、确认剩余冲突为空，并运行项目已有测试；自动复用只是减少重复编辑，不是业务语义审查。

总结

Git rerere 适合长期分支反复合并的场景：rerere.enabled=true 负责打开记录，第一次人工确认负责建立样本，后续合并负责尝试复用，而 git diff、git rerere remaining 和 git add 组成最后的验收边界。只要把自动化放在重复劳动上，把语义确认留给人，rerere 才能稳定地服务于日常合并。