当我尝试将 stage 合并到 master 时，我得到了这些奇怪的嵌套冲突行。 当我尝试选择我想要保留在vimdiff mergetool中的那个：diffg LO和：diffg RE它看似奇怪的变化，我永远无法获得正确的合并解析。
截图来自Notepad ++ compare插件。左侧是本地文件，右侧是远程文件。
冲突1：
冲突2：
我的猜测是合并标记与其他合并标记发生冲突，在它们周围放置合并标记。例如，当选择远程更改时，实际上现在冲突的下一个合并标记现在被解释为实际合并标记，但由于它们的原因，它不会选择合并标记的正确打开或关闭行。是嵌套的。
我尝试过简单地删除所有合并内容（合并标记及其显示的行，.orig.orig以及出现的_LO和_RE文件）并保留文件（真实文件和.orig文件）我希望他们的方式，但这对我没用。
您能解释一下这些冲突是如何运作的，我应该如何看待它们以及处理它们的选择有哪些？
另外，为了更好地理解合并，我想知道Git如何找到这些标记。根据我的尝试，我认为它会根据他们的位置记录来寻找它们，如果它们完全从它们应该被删除的话就会遇到问题？
答案 0 :(得分：0)
我的猜测为什么你有＆＃34;嵌套＆＃34;冲突是因为你留下了一场冲突而且是＃34; （在＆＃34;尚未解决＆＃34;但已提交）您尝试合并的一个分支中，现在您正在尝试合并＆＃34;再次＆＃34;您看到之前的冲突现在显示为另一个合并的一部分。您是否可以检查您尝试合并的修订版上的文件内容，并告诉我们情况确实如此？
答案 1 :(得分：0)
奇怪嵌套的冲突线。
我的猜测是合并标记正在与其他合并标记发生冲突，将合并标记放在它们周围
git rerere通常有助于记录和重用冲突合并，但是在考虑嵌套合并冲突时会失败。
但是Git 2.20（2018年第四季度）将为“ git rerere”极端情况添加修复程序，尤其是当无法在文件中解析冲突标记时。
请参见commit bd7dfa5，commit 4af3220，commit 5ebbdad，commit c0f16f8，commit 221444f，commit 93406a2，commit fb90dca，{{3} }（2018年8月5日）和commit 2373b65的commit 28fc9ab，commit c5d1d13，commit e69db0b（2018年7月14日）。
（由Thomas Gummerer (tgummerer)在Junio C Hamano -- gitster --中合并，2018年9月17日）
rerere：教导rerere处理嵌套冲突当前
rerere无法处理嵌套的冲突，遇到此类冲突会出错。
为此，请递归调用“handle_conflict”函数以规范化冲突。请注意，只有当用户提交带有冲突标记的文件，并在后续操作中获得包括该冲突的冲突时，才会产生此类冲突。
此处的冲突ID计算值得一些解释：
由于我们使用相同的
handle_conflict函数，因此嵌套冲突的标准化方式与非嵌套冲突的标准化方式相同，这意味着diff3情况下的祖先被剥离，并且冲突的部分按字母顺序排列。但是，冲突ID仅在顶级
handle_conflict调用中计算，因此它将包括“rerere”添加到输出中的标记。
例如。说存在以下冲突：<<<<<<< HEAD 1 ======= <<<<<<< HEAD 3 ======= 2 `>>>>>>> branch-2 `>>>>>>> branch-3~它会在原像中记录如下：
<<<<<<< 1 ======= <<<<<<< 2 ======= 3 .>>>>>>> .>>>>>>>，冲突ID的计算方式为
sha1(1<NUL><<<<<<< 2 ======= 3 .>>>>>>><NUL>)`
（.只是为了避免降价解释：应该读为>>>>>>>）
