git - 告诉 git 解决与第三个文件的冲突，这是答案

Question

我们有以下情况： 有人在没有任何 git 合并工具的情况下手动解决了很多（数万个）合并冲突，但手动解决并保存到另一个文件中尝试解决此问题时，我正在进行适当的合并。现在我知道如何解决所有冲突 - 以旧的手动解决文件中的冲突为例。有没有办法自动做到这一点 - 由“第三”解决？

标签： gitmergediffgit-merge

Answer 1

对这个问题的评论并不完全有意义；所以我怀疑有些评论可能已被删除（或者在任何情况下都没有出现在我面前），我希望我没有遗漏任何相关内容。那说：

在“单个文件的单个合并”级别，最好的解决方案是开始合并，当提示解决冲突时，将预先解决的文件复制到工作副本上；然后git add它并commit完成合并。 [1]

如果您只有一个文件的单个合并，那么这就是您应该做的；因为任何更自动化的设置将花费更多时间而不是仅仅执行它。

另一方面，如果您有很多文件（可能跨越多个合并），那么更多的自动化可能是有意义的。如果您可以为您的工作树设置一个并行目录结构，并将预先合并的文件放在该并行结构中各自的位置，那么cp -R就可以工作。或者，如果您将它们提交到 git 中，您也许可以使用git checkout <commit> -- <path>语法来获取固定版本。

我想如果你真的想变得花哨，你可以设置一个合并驱动程序来复制预合并文件并避免首先报告冲突；但是使该工作正常工作的设置仍然同样乏味（更糟糕的是，事实上，因为创建合并驱动程序的附加步骤），并且自动化只是意味着您将在有机会之前进行提交合并做最后的健全性检查......老实说，我不会理会这个想法。

---

[1] 在您的评论中，您说您担心日志显示单个更改而不是完全重写的文件，这就是我觉得缺少一些上下文的地方。无论如何，复制预先解决的文件以解决冲突本身不会导致 git 将文件视为“完全重写”。日志输出是一个计算出来的补丁。它显示了文件之间的差异，无论用于生成每个版本的过程如何。

因此，如果它显示“完全重写的文件”，则意味着它在每一行（或多或少）上都看到了差异。这可能是由于空白区域的变化（尤其是行尾变化在某些情况下往往会偷偷溜走）。或者某种无端的重新格式化。

如果发生这样的事情，并且如果您无法撤消预合并副本上的“不必要”更改，那么您可能必须决定是手动重做合并还是暂时忍受更好日志。