我是 Bitbucket 的新手，我正在尝试弄清楚如何将 rerere 用于拉取请求。

作为管理员，我想在有人真正尝试将它们与拉取请求合并之前尝试合并所有分支。如果我发现一个会导致合并冲突的分支，我可以提前解决它，并使用 rerere 保存解决方案。如果我可以将我的解决方案复制到 BitBucket 服务器，理论上它可以自动解决冲突。

不过，我有以下问题。

• 我不知道 BitBucket 在哪里进行合并
• 即使我这样做了，也没有允许使用 rerere 自动提交的设置。（请参阅此答案，这将有助于命令行）

我想知道是否有某种方法可以将某种钩子添加到拉取请求中，以允许我执行必要的命令来应用 rerere。

git rerere愉快地存储我的冲突解决方案，并在再次出现相同的冲突时自动应用它们。

但是，有时，我会遇到不希望自动合并的不同上下文的合并冲突。

有没有办法git rerere记住冲突解决方案，但需要显式调用git rerere才能应用它们？

需要明确的是，我不希望git rerere clearor git rerere forget，而是简单地说，除非明确指示，否则不会自动解决合并冲突（如果它可以在申请之前向我显示提议的解决方案，则奖励！）

Background

I am currently resolving a merge conflict with git rerere enabled. git status shows one unmerged path. When I view the file, there are no <<<<<<< HEAD or >>>>>>> <SHA> markers identifying the conflict, which tells me that rerere has done it's work and resolved the conflict according to how I have done it in the past.

I would like to confirm that rerere's resolutions are correct.

The merge process I am working on is very complex involving multiple remotes contributing to the Linux kernel. I did a test merge of several remotes yesterday with the goal of identifying conflicts, notifying maintainers, then discarding the resulting (surely broken) kernel. While doing so, I made a couple of careless conflict resolutions just to move on to the next remote, and called git rerere forget <pathspec> on all of the conflicting paths after I was done, including the one I'm dealing with now. Since I told rerere to forget this path, I don't know why it resolved anything on this run, and I'm concerned that it applied the fix that I made yesterday when I didn't care if the result was correct.

The Question

Is there any way to see what conflicts rerere resolved after it has already applied the resolution?

I would like to avoid restarting the merge because it's a long process that we don't have fully automated yet. Also, since I tried to tell rerere to forget this path yesterday and yet it still applied a resolution today, I think I would just end up in the same position if I don't find out why git rerere forget <pathspec> failed first.

Related Questions
Undo a git rerere resolution that was done in a rebase <-- solution requires restarting merge
Are there any downsides to enabling git rerere? <-- only discusses git rerere forget <pathspec>

Follow Up Note/Question
I just tried entering git rerere forget with no pathspec, which I'm aware is deprecated, but if I understand correctly, should make rerere forget all resolutions. I reran the merge and it still applied a resolution to the file. I also completely disabled rerere and ran the merge a third time so I could see the conflict, and rerere was indeed applying the half-hearted resolutions I did yesterday. Why is forget not correctly discarding resolution that I don't want to reuse?

git rebase --preserve-merges

该文档说“不保留合并冲突解决方案或手动修改合并提交”。

我了解如何通过使用来处理合并冲突rerere，但是对合并提交的手动修改究竟是什么？是否rerere也处理这个问题？如果没有，是否有解决方法？

合并后我得到下一个日志：

在此之后，我可以查看如何解决此合并冲突：

但是如何查看原始合并冲突？

man git rerere似乎没有这样的命令

原像是合并新旧文件的结果，我明白了。postimage是解决冲突的方式，我明白了。

但是这个图像是什么？

我经历了以下情况：

我在与 . 合并时遇到了冲突git rerere enabled。

我修复了冲突文件，但也必须调整其他非冲突文件。
所有触及的文件都已添加并提交。git rerere表示已记录该决议。

后来git pull --rebase=preserve重复合并冲突， git rerere 来救援。
但是，仅应用了冲突文件中的部分解决方案，其他文件中的更改未应用。
快速浏览 rr-cache 表明这些其他更改尚未记录。

git rerere 是否仅记录直接冲突文件中的更改而没有其他内容？

是否可以选择记录解决提交中所做的所有更改，而不仅仅是冲突文件？

我喜欢 rerere 的想法，但有一些可能的担忧，即它可能会导致我不想启用此功能的其他目录出现一些问题。这似乎是一个全有或全无的事情。这是正确的，还是我可以只为某些目录设置它？

我正在考虑将 rerere 缓存与此脚本给出的 repo 一起存储，因此需要进一步了解此功能。

编辑

如果没有，是否可以为我感兴趣的更改启用 rerere，然后再次将其关闭以限制使用它的位置？如果是这样，我会在流程的哪些部分执行此操作？

据我了解，通过保存冲突解决信息对项目同步很有用，但我并不完全清楚如何使用和配置它。

我想为我的持续集成 (CI) 环境进行配置。是否建议这样做？

请不要用另一个问题标记重复：启用 git rerere 有什么缺点吗？. 因为我的怀疑与“那么启用 rerere 有什么缺点吗？它会导致哪些潜在问题不会发生？”

我的工作流程通常包括merge -> resolve conflicts -> commit -> debug during compilation -> fixup commit. 通过这种方式，我随后将脏合并与清除合并。如果启用rerere，我将始终记录脏分辨率。如何绕过这个问题？有没有办法rerere通过提交来解决问题？