有没有一种很好的方法来解释如何在Git中解决合并冲突？
从git-merge的手册页中,您可以使用许多合并策略.
resolve - 这只能使用3向合并算法解析两个头(即当前分支和你从中拉出的另一个分支).它试图仔细检测纵横交错的合并模糊,并且通常被认为是安全和快速的.
递归 - 这只能使用3向合并算法解析两个磁头.当有多个可用于3向合并的共同祖先时,它会创建共同祖先的合并树,并将其用作3向合并的参考树.据报道,这可以减少合并冲突,而不会因为从Linux 2.6内核开发历史记录中进行的实际合并提交而导致错误合并.此外,这可以检测和处理涉及重命名的合并.这是拉动或合并一个分支时的默认合并策略.
章鱼 - 这解决了两个以上的案例,但拒绝进行需要手动解决的复杂合并.它主要用于将主题分支头捆绑在一起.这是拉动或合并多个分支时的默认合并策略.
我们的 - 这解决了任意数量的头,但合并的结果始终是当前的分支头.它旨在用于取代侧枝的旧发展历史.
子树 - 这是一个修改后的递归策略.当合并树A和B时,如果B对应于A的子树,则首先调整B以匹配A的树结构,而不是读取相同级别的树.这种调整也是对共同的祖先树进行的.
我什么时候应该指定不同于默认值的东西？哪些场景最适合？
维基百科称3向合并不像双向合并那样容易出错,而且通常不需要用户干预.为什么会这样？
3向合并成功并且双向合并失败的示例将是有帮助的.
我正在使用git来跟踪我的LaTeX文档的更改.我倾向于将共同作者的反馈保留在一个单独的分支中,并在以后合并.到目前为止,事情似乎神奇地合并,但我想知道何时发生合并冲突,以便我可以在合并过程中获得一些真正的信任(我当然不希望文本出来时髦).
StackOverflow上有很多问题似乎都提出了同样的问题,但没有一个问题非常具体.例如,这个答案指定如果对同一个区域进行了更改就会发生冲突,但这让我想知道这些区域到底是什么.是仅仅对同一行进行了更改,还是考虑了某些上下文？
我想测试一下一个分支是否可以合并到另一个分支中。例如，假设我想测试一个发布分支是否可以合并到 master 中，而不需要实际合并到 master 中。我想我会做这样的事情：
#!/usr/env/bin bash
git checkout master
git checkout -b master_temp
git merge my_release_branch
所以我认为如果退出代码为0，则合并成功，否则合并失败。
不过，这是我最关心的问题：假设合并成功，但它打开了交互部分。我怎样才能避免这种互动呢？有时在合并nano或vim打开期间，我们必须做一些事情（不确定做什么）。有办法把它关掉吗？
这个问题基本上是一样的，但是，这个问题并没有规定这需要由人类以外的任何人来完成。就我而言，它需要是自动/程序化的。
我在 Git 中有两个主要分支：master和dev.
我的分支结构如下所示：
B-->E-->F-->G (master branch)
B-->C-->D-->H-->I-->J-->K (dev branch)
之前，我进行了合并，master并dev有一个共同的母公司B。
在提交E，F并G掌握的，我删除了一些文件（说foo和bar）不正确，而他们在提交仍然存在C起在dev分支。
结果，当我执行三向合并以加入G并K创建 commit 时L，L不再包含 foo 和 bar ！Git 没有以任何方式通知我他们的失踪。
在我看来，由于E，F并G进行了简单的重播后提交C因此foo而bar都不见了。
Git 合并的这种行为对我来说很奇怪。因为我无法知道是否有人从另一个分支删除了一些文件。
我不应该至少在合并时收到有关任何冲突修改的通知吗？