什么是git-rerere，它如何工作? [英] What is git-rerere and how does it work?

问题描述

据我所知，它通过保存冲突解决信息来进行项目同步非常有用，但是对我来说，如何使用和配置它尚不完全清楚.

As I understood, it is useful for the synchronization of projects through the saving of conflict resolution information, but it is not entirely clear to me how to use and configure it.

我想为我的持续集成(CI)环境进行配置.建议这样做吗?

I want to configure for my continuous integration (CI) environment. Is it recommended do this?

请不要用其他问题标记重复项:是启用git rerere有什么缺点吗?.因为我的疑问与 无关，所以启用rerere有什么不利之处吗?它会导致哪些潜在的问题，否则将不会发生?"

Please don't mark a duplicate with this other question: Are there any downsides to enabling git rerere?. Because my doubt isn't related to "So is there any downside to enabling rerere?. What potential problems can it cause that would not otherwise occur?"

推荐答案

什么是git rerere?

作为文档注释，rerere代表 re 使用 re 编码的 re 解决方案.

What is git rerere?

As the documentation notes, rerere stands for reuse recorded resolution.

但这并不能真正解释它是什么.值得首先添加的是，git rerere本身(命令)不是您必须运行的东西.它只有六个子命令:clear，forget，diff，status，remaining和gc.这些都不记录或重复使用分辨率-实际上，git rerere clear和git rerere forget <path>只是放弃一些记录的分辨率. gc命令与此类似，但是所指的是旧的，而不是当前的.

That doesn't really explain what it is, though. It's worth adding first, here, that git rerere itself—the command—is not something you have to run. It has just six subcommands: clear, forget, diff, status, remaining, and gc. None of these record or reuse a resolution—in fact, git rerere clear and git rerere forget <path> just discard some recorded resolutions. The gc command is similar, but refers to ones that are old, rather than current ones.

大多数工作都来自rerere.enabled的设置(这使Git在适当的时候为您运行git rerere，没有子命令).您可以自己运行不带子命令的git rerere，但这实际上并没有做任何重要的事情，因为Git会自行执行.

Most of the work happens from the setting of rerere.enabled (which makes Git run git rerere, with no subcommand, for you, at the appropriate times). You can run git rerere with no subcommands yourself, but this doesn't really do anything important since Git will do that on its own.

一旦您设置了rerere.enabled，当Git进行合并时-任何合并，包括来自git am和git rebase以及git cherry-pick的合并，等等，而不仅仅是来自git merge本身的合并-都击中了冲突，Git将:

Once you have set rerere.enabled, when Git does a merge—any merge, including those from git am and git rebase and git cherry-pick and so on, not just those from git merge itself—and hits a conflict, Git will:

1. 记录(一旦动词合并击中它们)相互冲突的diff大块；
2. 等待您手动解决它们；
3. (在git commit时)记录您为解决这些问题所做的工作.

1. record (once the merge-as-a-verb hits them) the conflicting diff hunks;
2. wait for you to resolve them manually;
3. record (at git commit time) what you did to resolve them.

这里缺少一个步骤，这就是为什么它从2开始编号的原因.步骤1是:

There's a step missing here, which is why this is numbered starting at 2. Step 1 is:

1. 检查以前记录的解决这些冲突的方法:如果存在，请使用它们自动解决这些冲突.

1. check for previous recorded resolutions for these conflicts: if they exist, use them to resolve those conflicts automatically.

如果记录的分辨率完全解决了冲突，则步骤2-4将变得多余. Git可能仍会全部运行它们(我不确定是否会运行)以更新记录的分辨率上的时间戳.

If the recorded resolutions completely resolve the conflicts, steps 2-4 become redundant. Git may still run them all (I'm not sure that it does) to update the timestamps on the recorded resolutions.

一旦设置了rerere.enabled，合并本身的行为就会同时产生冲突和(因为它会自动运行git rerere而没有参数)记录它们，然后尝试重用任何现有记录的分辨率.记录最终分辨率的是提交操作(因为Git会自动为您再次运行git rerere).因此，这完全是自动的-您只需要通过运行自己的git diff命令来确保以前重用的分辨率是正确的.如果没有，只需修复它们的文件，然后像往常一样添加并提交，Git将用新的分辨率替换记录的分辨率.

Once you set rerere.enabled, it's the act of merging itself that both creates the conflicts and (because it automatically runs git rerere with no arguments) records them and then tries to re-use any existing recorded resolutions. It's the act of committing itself that records the final resolutions (because Git automatically runs git rerere again for you). So it is all automatic—you just need to make sure, by running your own git diff commands, that your previous re-used resolutions are correct. If not, just fix them files, add, and commit as usual, and Git will replace the recorded resolutions with the new ones.

请注意，您仍然必须git add和git commit！您应该始终检查合并结果(和/或运行测试)，尽管无论rerere.enabled设置如何，都应始终执行此操作.

Note that you must still git add and git commit! You should always inspect the merge results (and/or run tests)—though you should do this always, regardless of your rerere.enabled setting.

作为 VonC点在注释中，如果您有以前没有记录的现有合并冲突解决方案，则可以对这些解决方案重新培训"数据库. Git源代码中有一个有助于执行此操作的脚本；它也可以在线获得.

As VonC points out in a comment, if you have existing merge conflict resolutions you did not record earlier, you can "train" the rerere database on those resolutions. There is a contributed script in the Git source to do this; it's also available on-line.

这篇关于什么是git-rerere，它如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！