【问题标题】:Git markers started showing up when resolving conflicts with VS2019 + KDiff3解决与 VS2019 + KDiff3 的冲突时,Git 标记开始出现
【发布时间】:2020-10-07 14:57:49
【问题描述】:

今天我尝试合并两个分支,但遇到了冲突。我使用 Visual Studio 2019 Team Explorer,.gitconfig 是这样设置来启动 KDiff3 的:

[merge]
    tool = kdiff3
[mergetool "kdiff3"]
    path = C:/Program Files/KDiff3/bin/kdiff3.exe
    trustExitCode = false

到目前为止,这一直很好,但是今天在文件的基本版本中存在 Git 的冲突标记。像这样的:

Common code
<<<<<<<<< Temporary merge branch 1
One version of code
=========
Another version of code
>>>>>>>>> Temporary merge branch 2
More common code

这从未发生过。这些标记不是仅用于使用文本文件手动合并吗?关于如何解决这个问题的任何想法?

编辑:

另外,直接从命令行使用 git 具有相同的标记,但我不知道以前是否存在这些标记,因为我几乎从不使用命令行。这是我使用的命令:

git mergetool -g FileName.cs

【问题讨论】:

    标签: git visual-studio visual-studio-2019 git-merge kdiff3


    【解决方案1】:

    只要发生合并冲突,Git 就会添加这些标记。这是 Git 使冲突位置易于发现(通过人工或合并工具)并显示替代版本的方法。

    合并工具会检测这些标记,让用户更轻松地比较版本并选择他们喜欢的版本。 KDiff3 等 GUI 工具通常隐藏标记并在不同的窗格中显示替代版本。一旦用户解决了冲突,合并工具就会删除带有标记的行。

    其他工具允许轻松地从冲突跳转到冲突,以不同的颜色突出显示替代版本,并具有轻松解决冲突的键绑定,但它们不会向用户隐藏那些 Git 冲突标记(例如 ediff)。

    无论如何,无论您是否看到它们(取决于您使用的合并工具),它们都会一直存在,直到冲突得到解决。

    不知道这次KDiff3出了什么问题,但是手动修复很容易:

    您可以简单地使用任何文本编辑器打开文件,删除行

    <<<<<<<<< Temporary merge branch 1
    
    =========
    
    >>>>>>>>> Temporary merge branch 2
    

    然后选择One version of codeAnother version of code 或两者的组合(或完全其他)。

    完成后,保存文件,运行:

    git add <file>
    

    (这告诉 Git 你已经解决了冲突),然后:

    git commit
    

    您不必输入提交消息,因为 Git 会自动为您提供合并提交消息(您可以接受或修改)。

    等等。

    【讨论】:

    • 您确定三向合并工具了解冲突标记吗?我不认为这就是他们的工作方式。它们将三个没有标记的文件作为输入并生成一个输出文件。
    • 嗯。我以为他们做到了,但是阅读下面的答案后,我意识到我可能错误地理解了它们在幕后的工作方式。谢谢你让我质疑我之前的理解。我自己不使用 GUI 合并工具,我应该更多地研究它。
    • The answer 说了我写的同样的话:“kdiff3 将尝试为您合并琐碎的东西,并会根据 git 合并失败注释为您提供一个 4 窗格窗口来解决非琐碎的东西。”
    • 答案是正确的,但这并不意味着 KDiff3 会解释冲突标记。通常,启动外部工具时,标记甚至都不存在。 Git 生成三个文件,调用合并工具并告诉它把输入放在哪里。当合并工具关闭时,git 会询问您是否希望接受生成的输出文件。如果您在合并工具仍在运行时查看,您可以在文件系统中看到三个 git 生成的文件(后缀:base、local 和 remote)。
    【解决方案2】:

    事实证明这不会发生在正常的冲突中,这只是一个复杂的合并树的情况。对于与一个明显的单一共同祖先的正常合并冲突,git 生成三个简单的文件供合并工具查看。当冲突有多个共同祖先时,它会在“基础”文件中留下一些标记。

    【讨论】:

    • 我也不确定它是如何工作的:只要发生合并冲突,Git 就会留下这些标记。你不需要复杂的树和多个共同的祖先来实现这一点。
    • 每当 Git 必须在创建合并提交的过程中停止,因为其中至少有一大块文件存在冲突,Git 会放入这些标记。我可能完全错误地认为花哨的 GUI 合并工具是如何在幕后工作的,但我确信 Git 会这样做。
    • 很难找到有关花哨的合并工具如何在后台工作的信息。但是很容易看出 Git 做了什么:在您的 Git 配置文件中,删除您的合并工具 conf 并在没有合并工具的情况下使用 Git。创建简单的合并冲突,看看 Git 做了什么。
    • @prosoitos 我刚刚意识到这里也有 cmets。他们真的没有那么花哨。它们在没有 Git 的情况下工作,并且在 Git 之前就已经存在。它们采用三个文件:一个共同祖先(A)和两个版本(B 和 C)。然后他们逐行查看文件。如果一条线在 A 和 B 中相同而在 C 中不同,则从 C 输出该线(这意味着 C 修改了 B 自共同祖先 A 以来未触及的内容)。如果 B 和 C 相同而 A 不同,则意味着两个版本都进行了相同的编辑并选择了那个。否则,它表明您存在冲突,您需要做出决定。
    • @prosoitos git-scm.com/docs/git-mergetool "当使用此工具调用 git mergetool (...) 配置的命令行将被调用,其中 $BASE 设置为包含合并的公共基础(如果可用);$LOCAL 设置为包含当前分支上文件内容的临时文件的名称;$REMOTE 设置为包含要合并的文件内容的临时文件,$MERGED 设置为合并工具应写入的文件的名称合并解析的结果。"
    猜你喜欢
    • 1970-01-01
    • 2010-09-16
    • 1970-01-01
    • 2010-09-11
    • 1970-01-01
    • 2015-10-15
    • 1970-01-01
    • 1970-01-01
    • 2010-09-21
    相关资源
    最近更新 更多