从git-merge的手册页中,您可以使用许多合并策略.
resolve - 这只能使用3向合并算法解析两个头(即当前分支和你从中拉出的另一个分支).它试图仔细检测纵横交错的合并模糊,并且通常被认为是安全和快速的.
递归 - 这只能使用3向合并算法解析两个磁头.当有多个可用于3向合并的共同祖先时,它会创建共同祖先的合并树,并将其用作3向合并的参考树.据报道,这可以减少合并冲突,而不会因为从Linux 2.6内核开发历史记录中进行的实际合并提交而导致错误合并.此外,这可以检测和处理涉及重命名的合并.这是拉动或合并一个分支时的默认合并策略.
章鱼 - 这解决了两个以上的案例,但拒绝进行需要手动解决的复杂合并.它主要用于将主题分支头捆绑在一起.这是拉动或合并多个分支时的默认合并策略.
我们的 - 这解决了任意数量的头,但合并的结果始终是当前的分支头.它旨在用于取代侧枝的旧发展历史.
子树 - 这是一个修改后的递归策略.当合并树A和B时,如果B对应于A的子树,则首先调整B以匹配A的树结构,而不是读取相同级别的树.这种调整也是对共同的祖先树进行的.
我什么时候应该指定不同于默认值的东西？哪些场景最适合？
可能重复:
您何时会使用不同的git合并策略？
当git合并我正在处理的文件时,我看到:
Merge made by the 'recursive' strategy
什么是递归策略？还有哪些其他策略(如果有的话)？使用一个优于另一个会有什么好处？不同的策略有不同的表现吗？或者两种不同的策略会导致不同的合并结果？
我在的BASE文件中具有以下内容git merge：
<<<<<<<<< Temporary merge branch 1
- _modifiedTimeWeak = 4.25.2019::11:41:6;
- _lastID = 3;
- weakCGTime = 4.25.2019::11:42:20;
- strongCGTime = 1.2.1990::0:0:0;
=========
- _modifiedTimeWeak = 5.1.2019::8:52:36;
- _lastID = 3;
- weakCGTime = 5.1.2019::8:52:36;
- strongCGTime = 3.20.2019::17:13:20;
>>>>>>>>> Temporary merge branch 2
我现在已经对该文件进行了无基础的合并，因此没有未解决的问题，但是我想了解可能出了什么问题。
我已经检查了由标识的BASE提交git merge-base，并且它不包括所介绍的合并冲突，因此可以排除。这也是这是第一次，尽管在此存储库发生之前已经进行了许多合并。
可能值得注意的是，我正在使用git merge merge-tool。
执行合并时，可能导致BASE文件出现合并冲突的原因是什么，可以采取什么步骤来避免将来发生这种情况？