来自申请和藏匿的冲突

Question

在阅读一些教程/ stackoveflow内容时，我读到了存储和应用也会发生冲突。

例如:(来自git-scm/git-apply---3way

  

-3

     

- 3way

     

当补丁不能完全应用时，如果补丁记录了应该应用的blob的身份，则回退到3-way merge，   我们在当地有这些斑点，可能会离开   工作树中文件中的冲突标记供用户使用   解决。此选项隐含--index选项，并且不兼容   使用--reject和--cached选项。

When the patch does not apply cleanly是否等于发生冲突？

我们怎样才能解决冲突而不是合并操作？这些冲突与合并冲突有什么不同？我很想看到一些图表示例。

Answer 1

  

When the patch does not apply cleanly是否等于发生冲突？

否：当它无法找到目标文件（应用补丁的那个）中的大块（补丁上的一组线）的“上下文”时，它不会“干净地”应用。
A patch正在使用“context diffs”和“unified diffs”（也称为“unidiffs”），它围绕每个更改与上下文行（应该在修改前后的行）申请），以及范围（修改发生的行号）。 然后，补丁可以使用此“上下文”来定位要修补的区域，即使它已经被文件中较早的更改所替换，也可以使用差异中的行号作为起点。

但是如果目标的修改确实干扰了补丁（意思是：如果目标文件中的上下文不再存在，因为修改或删除了行），则它（补丁）不能完全应用。 / p>

  

我们怎样才能解决冲突而不是合并操作？

切换到3-way merge时，只会出现合并冲突 在这种情况下，您有一个共同的祖先，它使您能够知道块是否是来自原点的更改以及更改是否发生冲突。
在“Guiffy SureMerge - A Trustworthy 3-Way Merge”中查看有关三向合并的更多信息。