重新计算合并冲突（即如何生成冲突标记）

Question

我有一个合并冲突，其中大多数冲突是由代码格式引起的。

我的代码有

<<<
===
>>>

由 git 插入的标记，以帮助我解决冲突。

在这种状态下，我想重新格式化与要应用的提交对应的代码，然后重新计算合并冲突并重新插入标记，我想冲突会更容易查看。

如果重要，这是变基的一部分。

我想像在提交时检查冲突文件以应用，重新格式化它，然后“重新计算冲突”，解决冲突，然后git rebase --continue

这是可能的还是相关的可能？

Answer 1

我想像在要应用的提交时检查冲突文件，重新格式化它，然后“重新计算冲突”，解决冲突，然后git rebase --continue

这可能吗

不是直接，不是，而是：

或相关的可能？

与某事相关的部分是可能的。诀窍是使用git merge-file，而使用 git merge-file，你需要三个输入文件。

为了具体起见，我们将文件命名为f.py。也就是说，你已经启动了一个 rebase 并且与f.py 发生了冲突。你想跑：

git checkout --theirs f.py

获取您的版本，或者：

git checkout --ours f.py

将版本-so-far-in-the-rebase 放入您的工作树中。然后你想编辑这个，并尝试将它与另一个合并。

Git 最初使用的三个输入文件是：

• 合并库提交中f.py的副本；
• --ours 提交中f.py 的副本（以上两者之一）；和
• f.py 在--theirs 提交中的副本（上述两个中的另一个）。

然后，在这种情况下，Git 默认情况下，¹ 通过git merge-file 运行这三个文件，就像通过：

git show :1:f.py > f.py.BASE
git checkout --ours f.py         # or git show :2:f.py > f.py
git show :3:f.py > f.py.REMOTE
git merge-file f.py f.py.BASE f.py.REMOTE
rm f.py.BASE f.py.REMOTE

或多或少。²

您可以自己执行相同的操作。提取所有三个文件 - 例如，您可以调用中间一个 f.py.OURS 或 f.py.LOCAL，以帮助跟踪哪个是哪个，尽管 git rebase 的“我们/他们”“本地/远程”区别不存在;你可以在这里使用任何你喜欢的名字——对每个名字做任何你想做的事情。然后使用git merge-file：它将用合并结果覆盖first命名的文件。

---

¹如果没有可能冲突，Git 根本不需要做任何事情：Git 会计算出哪个文件将是这三个的结果-way 合并并直接放置到位。如果存在可能的冲突，Git 会提取所有三个文件并将它们合并。如果您定义了合并 驱动程序，Git 将使用您的合并驱动程序。否则 Git 将使用内置的合并驱动程序，该驱动程序使用与 git merge-file 相同的代码。

²“或多或少”部分是因为这些文件具有谨慎且不冲突的临时名称，例如 .gittmp0133145a 或其他名称，即使使用您自己的合并驱动程序也是如此。在内部进行合并时，Git 通常根本不需要任何临时文件。对于您想要做的事情，您可能需要编造一些临时文件名。

---

git checkout -m

请注意，上述方法与使用 git checkout -m <em>path</em> 不同，后者只是在特定文件中重新创建原始合并冲突。也就是说，在f.py 发生合并冲突后，您可能会运行：

vim f.py

并对其进行（并写出）一些更改以尝试解决冲突，然后意识到您刚刚所做的事情是完全错误的。要将文件恢复到 Git 最初的状态（恢复原始合并冲突），您可以运行：

git checkout -m f.py

或（自 Git 2.23 起）git restore -m f.py 以取回您在编辑器中覆盖之前的 f.py。

你也可以使用：

git restore --conflict=diff3 f.py

（或与git checkout类似）；见下文。

使用git mergetool 构建你想要的东西

git mergetool 命令提取git merge-file 需要的三个输入文件，然后在这些文件上运行一些选定的合并工具——任何你喜欢的程序。您也许可以使用它来获得良好的效果。我没有对此进行过实验，但请参阅my answer 至git cherry-pick: manually accept "our" or "their" hunks in conflicted files 上的this comment。一些谨慎的 pre-git mergetool 命令与相关文件的当前工作树副本，然后使用 git mergetool 和 git merge-file，可能会得到你想要的。

考虑 diff3 样式

您的情况（代码格式）可能不适合这种情况，但我发现将merge.conflictStyle 设置为diff3 会使cherry-pick 冲突更容易理解。如果由于缺少合并基本上下文而导致无法读取的冲突，则此diff3 样式有很大帮助。如果你不喜欢全局，或者只想在一个冲突中使用它，git checkout -m（旧方式）和git restore -m（新方式）都可以与--conflict=diff3一起使用。 （--conflict 部分暗示了-m 部分，因此您可以只使用--conflict 选项，或者如果您有这种习惯，也可以同时使用这两个选项，因为我来自古代 Git 1.6 天。）