据我了解，通过保存冲突解决信息对项目同步很有用，但我并不完全清楚如何使用和配置它。
我想为我的持续集成 (CI) 环境进行配置。是否建议这样做？
请不要用另一个问题标记重复：Are there any downsides to enabling git rerere?。因为我的疑问与“那么启用 rerere 有什么不利之处吗？它会导致哪些潜在问题不会发生？”
【问题讨论】：
标签： git version-control continuous-integration git-rerere
git rerere？正如the documentation 所说，rerere 代表重新使用重新有线重新解决方案。
不过，这并不能真正解释 它是什么。首先值得一提的是，git rerere 本身——命令——不是你必须运行的东西。它只有六个子命令：clear、forget、diff、status、remaining 和 gc。这些都没有记录或重用决议——事实上，git rerere clear 和 git rerere forget <path> 只是丢弃一些记录的决议。 gc 命令类似，但指的是旧的，而不是当前的。
大部分工作发生在rerere.enabled 的设置（这使得Git 在适当的时间运行git rerere，没有子命令）。您可以自己运行 git rerere 而不使用子命令，但这并没有真正起到任何重要作用，因为 Git 会自行完成。
git config rerere.enabled true一旦你设置了rerere.enabled，当Git 进行合并时——任何合并，包括来自git am 和git rebase 和git cherry-pick 等等，而不仅仅是来自git merge 本身的那些——然后点击冲突，Git 会：
git commit 时间）您为解决这些问题所做的工作。这里少了一个步骤，所以从 2 开始编号。步骤 1 是：
如果记录的解决方案完全解决了冲突，则步骤 2-4 变得多余。 Git 可能仍会全部运行它们（我不确定它是否会运行）以更新记录分辨率的时间戳。
一旦你设置了rerere.enabled，合并自身的行为就会产生冲突和（因为它会自动运行git rerere而不带参数）记录它们然后尝试重新使用任何现有的记录决议。记录最终解决方案的是提交自己的行为（因为 Git 会自动再次为您运行 git rerere）。所以这一切都是自动的——您只需要通过运行自己的git diff 命令来确保您之前重复使用的分辨率是正确的。如果没有，只需像往常一样修复文件、添加和提交，Git 就会用新的解决方案替换记录的解决方案。
请注意，您仍然必须git add 和git commit！您应该始终检查合并结果（和/或运行测试）——尽管您应该始终这样做，无论您的 rerere.enabled 设置如何。
作为VonC points out in a comment，如果您有之前未记录的现有合并冲突解决方案，您可以根据这些解决方案“训练”rerere 数据库。 There is a contributed script in the Git source to do this; it's also available on-line.
【讨论】：
rerere.enabled"...嗯，是的，但是不要忘记你可以训练 rerere 在过去冲突解决时完成的尚未 启用。手动 (stackoverflow.com/a/4155237/6309) 或通过 contrib/rerere-train.sh 脚本 (stackoverflow.com/a/45664714/6309)
train 脚本是我一直想要的。
git help rerere 页面不清楚何时会发生这种情况。
为您的 CI 环境启用 rerere 没有任何意义，因为您的 CI 环境从一开始就不应该解决合并冲突。为什么你认为你会想要它？
【讨论】：