https://git-scm.com/book/en/v2/Git-Tools-Rerere

rerere 的一些性质

rerere 没有默认开启。

rerere 是在前一步骤合并冲突，生成了含有冲突 markers 的文件之后，根据记录的结果重新应用冲突解决方案的。因而可以手动对冲突了的文件（通过 git checkout --conflict=merge -- <files> 创建）应用 git rerere。

rerere 可以自动解决冲突，但是解决过程发生在冲突之后，也不会自动提交，因此 rerere 在实现上更像一个钩子。这样也可以给使用者再次检查的机会。解决冲突之后把 unmerged paths 加入到 index，然后用 git commit 或者 git rebase --continue 来确认。

rerere 的缺点

rerere 不知道什么合并方式是正确的、什么是错误的，因而会一律记录下来。比如有时候合并错误需要退回，这个时候重新合并，rerere 就会用错误的方式解决冲突。使用 git rerere forget <pathspec> 可以让 rerere 删除错误的合并方式，将 <pathspec> 换成 . 就是删除本文件夹的所有冲突解决方式（注意当前是否在 git 仓库的根目录）。见 https://stackoverflow.com/questions/5519244/are-there-any-downsides-to-enabling-git-rerere 。

还有人指出：

Rerere can reuse previous resolution even though you were merging two branches with different contents than the one you resolved earlier.

好像合并方式是按照 chunks 来的，所以即便是文本内容不同，但是片段相同，也可以使用相同的方式合并？

可以用 git rerere gc 来删除一些比较老的解决方式的缓存，默认情况下未解决的是 15 天，解决的是 60 天。这个可以通过配置修改。