Git 怎样用 rerere 减少重复冲突处理

如果一个长期分支反复合并主干，同一组冲突可能要解决两三次。Git 的 rerere（reuse recorded resolution）可以记录已经完成的冲突解决，并在相同冲突再次出现时尝试复用；它不会替你判断业务语义，也不会代替最后的差异检查。

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

先确认 Git 版本与仓库入口

本文按 VS Code 的日常工作路径来操作：左侧进入“源代码管理”，再用“终端”菜单打开集成终端。图片是原创界面说明图，菜单文字用来帮助定位，不代表某个版本的实际截图。

先在集成终端执行下面的检查。注释只说明检查目的，不会改变命令本身。

# 查看 Git 版本，确认当前命令来自 Git 而不是其他工具
git --version

# 查看当前仓库状态，先确认没有需要隐藏的未提交改动
git status --short

# 查看当前仓库根目录，避免在错误目录写入配置
git rev-parse --show-toplevel

看到仓库根目录和干净的状态后，再配置 rerere。若当前工作区有未提交文件，先保存或暂存它们，避免把无关改动混入冲突复现。

打开 rerere，并把最终暂存留给自己

在集成终端运行两项仓库级配置。rerere.enabled 负责记录和尝试复用解决方案；rerere.autoUpdate 设为 false 时，即使 Git 找到可复用结果，也不会替你把索引标记为已解决。

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

# 保留人工复核和 git add，不让复用结果直接进入索引
git config rerere.autoUpdate false

# 逐项读取配置，确认写入的是当前仓库
git config --local --get rerere.enabled
git config --local --get rerere.autoUpdate

如果两行结果分别是 true 和 false，设置已经生效。这里不建议一开始就打开 autoUpdate：重复冲突的文本可能相同，但业务上下文未必相同，把暂存动作留给人工更容易发现误用。

第一次冲突后留下可复用记录

以“功能分支反复合并主干”为例，先通过 VS Code 的“终端 → 新建终端”执行合并命令。发生冲突后，左侧“源代码管理”会出现冲突文件，编辑器中也会显示当前分支与传入分支的冲突区域。

# 把主干合入当前功能分支，示例分支名按仓库实际情况替换
git merge main

# 查看 rerere 认为仍处于冲突状态的文件
git rerere status

# 查看当前解决内容相对冲突状态的差异
git rerere diff

在编辑器里选择“保留当前内容”“接受传入内容”或手动合并后，继续用“查看差异”确认最终文本。确认无误后在“源代码管理”面板点击“暂存更改”，或执行：

# 暂存已经人工检查过的冲突文件，而不是盲目暂存全部文件
git add path/to/conflicted-file

# 再看一次工作区差异，确认没有遗留冲突标记
git diff --check

# 完成这次合并提交，让 rerere 记录本次解决结果
git commit -m "记录一次主干合并冲突解决"

关键点是“解决文本”和“暂存/提交”是两个动作。只有经过人工确认的结果才适合成为后续复用的依据。

第二次冲突检查自动复用结果

当同一分支关系再次产生相同冲突时，Git 会尝试调用已记录的解决方案。这个动作可能在合并或变基过程中自动发生，也可以在冲突现场手动执行 git rerere。无论哪种方式，都要把它当成候选结果，而不是最终答案。

# 再次合并后，查看仍未解决的文件
git rerere remaining

# 显示 rerere 对当前冲突应用的解决差异
git rerere diff

# 检查工作区和索引，确认复用结果没有引入无关改动
git diff
git diff --cached

如果 remaining 没有输出，说明 rerere 没有报告仍待处理的路径，但仍要阅读 git diff。由于这里关闭了 autoUpdate，复用结果写入工作区后仍需要你确认并执行 git add，随后再提交。

哪些情况应该清理 rerere 记录

如果之前的解决方案已经过时，或者你发现某个文件的复用结果不再符合业务规则，可以按路径忘记它：

# 只忘记当前冲突文件的旧解决方案
git rerere forget -- path/to/conflicted-file

# 放弃本次合并时清理当前冲突元数据
git rerere clear

# 清理 Git 认为已经过期的 rerere 记录
git rerere gc

forget 适合局部修正，clear 影响当前冲突元数据，gc 则按 Git 的保留规则清理旧记录。不要把它们当作“修复冲突”的快捷键，清理后下一次仍需要人工解决。

常见问题

为什么打开 rerere 后没有自动解决？

它只对能匹配到已记录冲突的场景有效；冲突上下文、文件内容或冲突结构变化后，Git 可能无法复用，仍需人工处理。

rerere 自动应用后可以直接提交吗？

不建议直接提交。先看 git rerere remaining、git rerere diff 和普通 git diff，确认业务含义正确，再执行 git add 和提交。

怎样让团队共享 rerere 记录？

rerere 记录属于本地仓库元数据，不应把个人缓存当作团队事实源。团队仍应通过代码评审和提交历史共享最终解决结果。

最终确认

完成后可以记住一条稳定路径：配置启用 → 第一次冲突人工解决并提交 → 第二次冲突先检查再暂存 → 记录失效时按路径清理。这样 rerere 承担重复劳动，最终判断仍由开发者负责。