什么构成Git中的合并冲突？ [英] What constitutes a merge conflict in Git?

问题描述

我的猜测会是这样的：如果两个提交合并了一个共同的父提交，如果他们都改变了行X从父母有，这是一个冲突。

我的理解是复杂的：

• 更改行X可能意味着将其替换为几行新行，并且仍然显示为一个冲突（版本A具有这一行，版本B具有这些行5行，或其他）
  
• 如果您在其中一个提交中插入了行，则一个dumber算法会认为所有后续行都已更改：第30行有第25行的前一个内容，31有26的前一个内容，等等。但是git可以说这些都是一样的，我也不知道怎么做。

任何人都可以解释这是如何工作的，或者指向我的链接吗？

基本上， git的的，每一个合并冲突，这让你有一个包含三个版本，每个文件，版本从每个分支和基地的索引。在这个索引上，运行了各种解析器，它可以为每个单独的文件决定如何解决此问题。

第一阶段是一个简单的解析器，它负责处理比如未修改的文件，一个分支修改了文件而另一个分支没有修改，或者两个分支都包含相同新版本文件的情况。

然后，它是查看其余案例的插件。有一个插件通过识别一个分支中的个体变化（比如差异）来处理文本文件，并尝试将这些变化应用到另一个分支，如果这样做不起作用，则会重新放置冲突标记。您现在可以轻松地在自己的合并工具中挂钩，例如，您可以编写一个知道如何在不违反格式良好的情况下合并XML文件的工具，或者提供允许交互式编辑和旁通的图形用户界面（例如，kdiff3做到这一点）。

因此，冲突的呈现实际上是使用插件的问题;文本文件的默认插件将使用与CVS相同的样式，因为人们和工具都习惯于它，冲突标记在几乎任何编程语言中都是已知的语法错误。

How does git determine that a particular merge has a conflict and what the conflict is?

My guess would go something like this: if the two commits being merged have a common parent commit, and if they have both changed line X from what the parent had, that's a conflict.

What complicates my understanding is:

• "Changing line X" can mean replacing it with several new lines, and that's still shown as one conflict (version A has this one line, and version B has these 5 lines, or whatever)
• If you did insert lines in one of the commits, a dumber algorithm would think that all subsequent lines had changed: Line 30 now has the former contents of line 25, 31 has the former contents of 26, etc. But git can tell that those are the same, and I don't know how.

Can anybody explain how this works, or point me to a link that does?

解决方案

Basically, with git, every merge is a conflict, which leaves you with an index that contains three versions of each file, the versions from each branch and the base. On this index, various resolvers are run, which can decide for each individual file how to resolve the matter.

The first stage is a trivial resolver, which takes care of things like unchanged files, cases where one branch has modified a file while the other didn't, or where both branches contain the same new version of the file.

Afterwards, it's plugins that look at the remaining cases. There is a plugin that handles text files by identifying individual changes (like diff) in one branch and trying to apply those to the other branch, falling back on placing conflict markers if that doesn't work. You can easily hook in your own merge tool at this point, for example, you could write a tool that knows how to merge XML files without violating well-formedness, or that gives a graphical user interface that allows interactive editing and a side-by-side view (for example, kdiff3 does that).

So the presentation of conflicts is really a matter of the plugin used; the default plugin for text files will use the same style as CVS did, because people and tools are used to it, and the conflict markers are a known syntax error in almost any programming language.

这篇关于什么构成Git中的合并冲突？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！