何时合并失败？

Question

我一直在使用SCM（SVN，Git）一段时间，它们的合并稳健性一直令人费解。有时自动合并工作，有时他们不工作。是否有关于什么会自动合并以及什么不合并的一般规则？

Answer 1

我认为问题是对版本管理的工作方式缺乏了解。版本管理不是灵丹妙药，它无法读懂思想。因此，如果两个人正在协作文件，并且如果文件的一部分存在冲突的更改，那么系统（git ..可能具有最佳合并功能）将不知道要保留哪个版本。 （它没有优先考虑其他变化），因此需要人工干预。

这不是版本控制机制的限制，而是非常关键的功能。有时，当您对同一段代码进行了相互冲突的更改时，系统不应合并。 （因为两个合作者之一所做的更改将会丢失）。

Answer 2

基本上，当编辑一行时，合并将失败，该行也由其他人编辑或者他们编辑了相邻的行。解决合并冲突的Git比subversion好一点。为了避免冲突尽可能频繁地提交（对源进行的每次原子更改都是理想的）。

另外see Resolving a Merge Conflict

Answer 3

一般情况下，如果SCM可以自行弄清楚如何创建一个包含您要合并的所有分支的所有更改的新版本，或者至少如果它认为可以计算它，则合并将自动成功进行。

如果文件只在一个分支中更改而在另一个分支中没有更改，则解决方案很明显：获取更改的文件。当文件在两个不同的分支中以不同的方式被更改时，事情才变得有趣，因为那时SCM需要一种方法来组合这些变化。

现在变得更加具体和实用，大多数SCM只能合并文本文件。我们以图像文件为例：可能在两个不同的分支中更改了图像的两个不同的，非重叠的部分。从理论上讲，可以自动合并，但大多数SCM没有算法，因此它们只会显示与整个文件的冲突。

那么，文本文件怎么样？这里，SCM确实具有用于组合变化的算法。这些通常将行视为基本工作单元。说得有点简化，如果第一个和第二个分支中的行改变不重叠，则合并将成功。如果它们会这样做，即如果在两个分支中改变了相同的行（或相邻的行），它将失败。正如我所说，事实有点复杂，但这应该是为了得到一般的想法。

最后，您还应该意识到即使成功没有问题，自动合并也可能是错误的。例如，将句子“Git可以合并”视为存储库中的数据。现在，分支A将其更改为“Git can bisect”，而分支B将其更改为“CVS can merge”。这两个更改位于不同的位置，因此理论上您可以自动合并它们。正如我上面所说的，大多数SCM不会因为它在同一行，但它只是一个例子:)。因此，合并两个分支将导致“CVS可以平分”，这显然是错误的。但这种问题并不经常发生。