重新计算合并冲突即如何生成冲突标记 git checkout -m使用git mergetool构建您想要的考虑 diff3 风格

如何解决重新计算合并冲突即如何生成冲突标记 git checkout -m使用git mergetool构建您想要的考虑 diff3 风格

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

我的代码有

<<<
===
>>>

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

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

如果有关系，这是变基的一部分。

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

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

解决方法

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

这可以吗

不是直接的，不是，而是：

或者有什么相关的可能？

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

为了具体起见，我们将文件称为 f.py。也就是说，您已启动变基并与 f.py 发生冲突。你想跑：

git checkout --theirs f.py

获取您的版本，或：

git checkout --ours f.py

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

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

• merge base 提交中 f.py 的副本；
• f.py 提交中 --ours 的副本（以上两个之一）；和
• f.py 提交中 --theirs 的副本（上述两个中的另一个）。

然后，在这种情况下，默认情况下，¹ 通过 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：它将用合并结果覆盖第一个命名文件。

---

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

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

---

git checkout -m

请注意，以上与使用 git checkout -m path 不同，后者只是在特定文件中重新创建原始合并冲突。也就是说，在 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 需要的三个输入文件，然后对这些文件运行一些选定的合并工具（您喜欢的任何程序）。您可以使用它来取得良好的效果。我还没有尝试过这个，但请参阅 this comment 到 my answer 上的 git cherry-pick: manually accept "our" or "their" hunks in conflicted files。一些谨慎的 pre-git mergetool 命令和相关文件的当前工作树副本，然后使用 git mergetool 和 git merge-file，可能会得到你想要的。

考虑 diff3 风格

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