我已经使用SCM（SVN、Git）一段时间了，它们的合并健壮性一直令人困惑。有时自动化合并有效，有时则不然。有没有关于哪些会自动合并，哪些不会自动合并的一般规则？
本质上，当一行被其他人编辑或编辑了相邻行时，合并将失败。Git在解决合并冲突方面比subversion好一点。为了帮助避免冲突，尽可能频繁地提交（对源进行的每个原子更改都是理想的）。
另请参阅解决合并冲突
我认为问题在于对版本管理的工作方式缺乏了解。版本管理不是万能药，它不能读懂思想。因此，如果两个人在一个文件上进行协作，并且文件的一部分发生了冲突性的更改，那么系统（git..可能具有最好的合并功能）将不知道要保留哪个版本。（它不会将一个更改优先于另一个更改），因此这需要手动干预。
这不是版本控制机制的限制，而是一个非常关键的功能。有时，当您对同一段代码进行了冲突的更改时，系统不应该合并。（因为两个合作者中的一个所做的更改将丢失）。
通常情况下，如果SCM能够自己找到如何创建一个新版本，其中包含您正在合并的所有分支的所有更改，或者至少如果它认为自己能够找到，则合并将自动成功。
如果一个文件只在一个分支中更改，而在另一个分支没有更改，那么解决方案是显而易见的：取更改后的文件。只有当一个文件在两个不同的分支中以不同的方式更改时，事情才会变得有趣，因为SCM需要一种方法来组合这些更改。
现在，为了变得更加具体和实用，大多数SCM只能合并文本文件。让我们以一个图像文件为例：也许图像的两个不同的、不重叠的部分在两个不同分支中发生了更改。理论上，可以自动合并，但大多数SCM没有这样的算法，所以它们只会向您显示与整个文件的冲突。
那么，文本文件呢？在这里，SCM确实有用于组合更改的算法。这些通常将线视为基本的工作单元。简单地说，如果第一个分支和第二个分支中更改的行不重叠，合并就会成功。如果它们这样做，即如果两个分支中的同一行（或相邻行）都发生了更改，则它将失败。正如我所说，事实有点复杂，但这应该是为了获得大致的想法。
最后，您还应该意识到，即使自动合并成功而没有问题，它也可能是错误的。例如，将句子"Git可以合并"视为存储库中的数据。现在，分支A将其更改为"Git可以平分"，分支B将其更改为由"CVS可以合并"。这两个更改位于不同的位置，因此理论上可以自动合并它们。正如我上面所说，大多数SCMs不会，因为它在同一行，但这只是一个例子：）。因此，合并这两个分支将导致"CVS可以平分"，这显然是错误的。不过，这种问题并不经常发生。