Git rerere 怎样自动复用已解决的冲突

如果一个仓库长期维护主题分支，合并或变基时可能反复遇到同一组冲突。Git rerere 的作用是记录第一次人工解决冲突的结果；以后再次出现相同冲突形态时，Git 会尝试复用这份记录。它能减少重复编辑，但不会替你判断业务逻辑是否仍然正确，所以复用完成后仍要看差异、测试和提交范围。

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

先看最终结果：复用成功应该看到什么

配置完成后，仓库里应能读取到 rerere.enabled=true。第一次解决冲突并继续合并后，Git 会保存对应的冲突与解决方案记录；再次遇到相同冲突时，工作区可能已经被套用解决结果。验收时重点看三件事：git status 是否还列出未解决文件、git diff 是否包含你认可的内容、git rerere remaining 是否仍有需要人工处理的路径。

这里的“相同”指冲突上下文足够接近，不是文件名相同就一定能复用。分支内容、冲突上下文或业务意图变化后，旧记录可能不适用；自动套用的结果必须当作候选修改来审阅。

步骤一：在仓库中开启 rerere

Git rerere 由 rerere.enabled 控制。为了只影响当前项目，可以在目标仓库根目录执行下面的命令；如果团队明确希望所有仓库默认开启，再考虑使用全局配置。

# 只为当前仓库开启冲突解决记录
git config rerere.enabled true

# 查看当前仓库实际读取到的配置
git config --get rerere.enabled

输出为 true 后，再打开合并工具或冲突文件。不要只凭“配置命令没有报错”判断成功，配置读取结果才是后续操作的起点。

步骤二：完成第一次冲突并让记录留下来

当合并产生冲突时，先按正常流程判断业务意图，手动编辑冲突文件，删除冲突标记并保存。确认内容后暂存文件，再继续当前操作：

# 把已经人工检查过的冲突文件加入暂存区
git add path/to/conflicted-file

# 合并场景继续完成合并；变基场景可替换为 git rebase --continue
git merge --continue

如果命令提示仍有未解决路径，说明还有文件没有处理完，先用 git status 找出它们。第一次记录的价值在于“人工确认过的解决结果”，不要把未经检查的大范围替换直接当成可复用答案。

步骤三：再次冲突时按顺序核对复用结果

下次合并或变基遇到相同冲突时，先看工作区状态，再看具体差异。Git 可能已经自动套用了历史解决方案，也可能只复用了其中一部分：

# 先确认哪些文件仍处于未解决状态
git status

# 查看自动套用或其他合并操作留下的具体差异
git diff

# 列出仍需要人工处理的 rerere 路径
git rerere remaining

若 git status 不再列出冲突文件，也不要跳过 git diff。应逐个确认关键分支条件、配置字段和错误处理仍符合当前分支的目标；确认后再执行 git add 和继续合并。

步骤四：错误记录怎样撤销，旧记录怎样回收

如果第一次解决时选错了业务版本，之后可能不断复用错误结果。针对某个路径，可以用 forget 删除记录，再重新人工解决：

# 删除指定路径的历史解决记录，下一次重新人工确认
git rerere forget -- path/to/conflicted-file

# 回收长期不再使用的旧记录
git rerere gc

forget 适合纠正单个文件或单类冲突；gc 适合周期性清理不再需要的记录。不要因为一次复用结果不理想就清空整个仓库的记录，先定位具体路径，避免丢失其他已经验证过的解决经验。

给团队留下一条可执行的使用约定

推荐把 rerere 当作“减少重复劳动的辅助记录”，而不是合并门禁：在经常重复合并的仓库级开启；首次解决必须人工审阅；再次复用后必须看 git diff 并运行项目测试；业务规则变化或发现错误记录时，用 git rerere forget 精确清理。这样既能减少重复冲突编辑，也不会把旧分支的判断悄悄带进新业务。

相关问题

Git rerere 会自动提交合并结果吗？

不会。它主要记录并尝试复用冲突解决结果；暂存、继续合并、提交以及最终代码审阅仍由你完成。

为什么开启后这次冲突没有复用？

可能是冲突上下文已经变化、历史记录尚未形成，或者当前仓库没有读取到 rerere.enabled=true。先检查配置和 git status，再判断是否属于同一类冲突。

应该全局开启还是只在仓库开启？

经常重复同步同一主题分支的项目适合仓库级开启；如果不同项目的分支策略差异很大，先使用仓库级配置更容易控制记录范围和清理责任。