什么是 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?

请不要用这个其他问题标记重复:Are启用 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 代表 reuse recorded resolution.

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 只是丢弃一些记录的分辨率.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 的 setting(这使得 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. 记录(一旦合并作为动词命中它们)冲突的差异大块；
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 积分在评论中，如果您有之前没有记录的现有合并冲突解决方案，您可以训练"这些解决方案的 rerere 数据库.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屋！