用 Git rerere 自动复用冲突解决策略，逃离重复冲突地狱

在维护长期功能分支时，开发者经常陷入一种令人沮丧的循环：为了跟上主分支的更新，你需要定期执行 merge 或 rebase 操作，每次都可能遇到相同的冲突，然后花费大量时间重新解决那些你已经解决过无数次的问题。这种重复劳动不仅浪费时间，还容易在手动操作中引入新的错误。Git 内置的 rerere（reuse recorded resolution）功能正是为解决这个问题而生 —— 它通过记录冲突解决的 "肌肉记忆"，让你只需解决一次冲突，后续遇到相同冲突时即可自动复用之前的方案。

rerere 的工作原理

rerere 的核心机制建立在 "镜像记录" 的概念上。当你启用该功能后，Git 会在后台默默完成三件事：首先，当冲突发生时，记录冲突文件的 "前镜像"（preimage），即包含冲突标记的原始状态；其次，当你手动编辑文件解决冲突并执行 git add 时，记录 "后镜像"（postimage），即你最终确定的解决方案；最后，当下次遇到完全相同的冲突前镜像时，自动应用对应的后镜像完成冲突解决。

这种匹配是精确到字节级别的。rerere 会对整个冲突文件的状态进行指纹计算，只有当新的冲突与之前记录的 preimage 完全一致时，才会触发自动解决。这意味着如果同一个文件在不同时间出现了额外的冲突点，或者冲突上下文发生了变化，rerere 不会进行部分匹配，而是将整份文件视为新的冲突场景。

启用与配置

rerere 默认处于关闭状态，需要显式启用。最推荐的方式是全局配置，这样所有仓库都能受益：

git config --global rerere.enabled true

也可以在单个仓库中启用：

git config rerere.enabled true

启用后，rerere 会在 .git/rr-cache/ 目录下存储所有的冲突解决记录。每个子目录包含一对 preimage 和 postimage 文件，你可以随时查看这些记录来了解 rerere 记住了哪些解决方案。如果需要清空记录，可以直接删除该目录下的内容。

实际工作流程示例

假设你正在开发一个功能分支，需要定期从 main 分支同步更新。在第一次合并时，config.js 文件出现了冲突：

<<<<<<< HEAD
const PORT = 3000;
=======
const PORT = 8080;
>>>>>>> feature/new-api

你决定将端口保持为 3000，编辑文件后执行 git add config.js。此时 rerere 已悄悄记录下这个解决方案。几天后，当你再次 rebase 功能分支时，Git 尝试应用相同的提交，冲突再次出现。但这一次，rerere 识别出完全相同的冲突指纹，自动输出：

Resolved 'config.js' using previous resolution.

你的 config.js 文件已经被设置为 const PORT = 3000;，无需任何手动干预。这种自动化在长生命周期分支的管理中尤为珍贵，特别是当你需要反复测试合并结果、保持分支最新状态，或者在多个集成分支之间同步功能时。

局限性与使用建议

rerere 的精确匹配机制既是优势也是限制。它要求冲突的完整上下文完全一致，这意味着：

• 如果文件 A 上次在第 10 行和第 50 行有冲突，这次只在第 10 行有冲突，rerere 不会自动解决
• 如果上次有 2 个冲突点，这次有 3 个冲突点，同样不会触发自动解决
• 冲突记录是按仓库隔离的，无法在不同仓库之间共享

基于这些特性，建议将 rerere 纳入日常开发工作流：在团队协作中统一启用，减少因频繁同步主分支而产生的重复冲突解决工作；在个人开发中配合频繁的小步 rebase 使用，保持功能分支的整洁；在 CI/CD 流程中利用 rerere 缓存加速自动化的合并测试。

结语

rerere 是 Git 工具箱中被低估的利器。它不需要改变你的工作习惯，只需一次简单的配置开启，就能在后续的开发过程中持续节省时间。对于那些长期维护特性分支、频繁进行代码同步的开发者而言，rerere 提供了一种 "解决一次，复用多次" 的优雅方案，让开发者从重复劳动中解放出来，将精力集中在真正有价值的代码编写上。

参考来源

• Git - Rerere - Git 官方文档对 rerere 功能的详细说明
• Stop Re-Resolving the Same Git Conflicts with rerere - asyncbits.dev 对 rerere 工作原理的实践解读

systems