Git如何解决合并问题？

Question

SVN降低了分支的成本，使分支变得更加容易，但是合并仍然是SVN中的一个实际问题-Git可以解决这个问题。

Git是否可以实现这一目标？

（免责声明：我对Git的所有了解都是基于Linus的演讲-总git noob在这里）

Answer 1

Git不会阻止合并中的冲突，但是即使它们不共享任何父祖先，也可以协调历史记录。（通过嫁接文件（.git/info/grafts），它是提交的列表，每行一个提交，后跟其父级，您可以出于“和解”的目的进行修改。）如此强大。但是要真正了解“如何考虑合并”，您可以从Linus自己开始，然后意识到这个问题与“算法”并没有太大关系：莱纳斯（Linus）：我个人来说，我想拥有一种非常可重复且非巧妙的东西。我了解或告诉我它做不到的事情。坦率地说，合并单个文件的历史记录而不考虑其他所有文件的历史记录会使我“很烦”。合并的重要部分不是如何处理冲突（如果冲突很有趣，则无论如何都要由人来验证），而是应该将历史融合在一起，以便为将来的合并奠定新的坚实基础。换句话说，重要的部分是琐碎的部分：给父母命名，并跟踪他们的关系。不是冲突。似乎有99％的SCM人似乎认为解决方案是对内容合并更加聪明。这完全错了重点。因此Wincent Colaiuta补充说（我的重点是）：不需要花哨的元数据，重命名跟踪等。您唯一需要存储的是每次更改前后的树状态。什么文件被重命名？哪些被复制？哪些被删除？添加了哪些行？哪些被删除？其中哪些行进行了更改？哪些文本是从一个文件复制到另一个文件的？您不必关心这些问题中的任何一个，当然也不必保留特殊的跟踪数据来帮助您回答它们：对树的所有更改（添加，删除，重命名，编辑等）都是隐式的编码在树的两种状态之间的增量中 ; 你只跟踪什么内容。绝对可以（并且应该）推断一切。Git打破了常规，因为它只考虑内容而不是文件。它不跟踪重命名，而是跟踪内容。它是在整个树级别上执行的。这与大多数版本控制系统完全不同。尝试存储每个文件的历史记录不会麻烦。而是将历史记录存储在树级别。执行差异时，您要比较的是两棵树，而不是两个文件。另一个根本上明智的设计决策是Git如何合并。合并算法很聪明，但不要试图太聪明。明确的决定是自动做出的，但是如果有疑问，则由用户决定。这是应该的方式。您不希望机器为您做出这些决定。您永远不会想要它。这是Git合并方法的基本见解：虽然其他所有版本控制系统都在试图变得更智能，但Git却自称为“愚蠢的内容管理器”，并且这样做更好。

Answer 2

上面的答案都是正确的，但我认为它们对我来说错过了git轻松合并的中心点。SVN合并要求您保持跟踪并记住已合并的内容，这是一个巨大的PITA。从他们的文档：svn merge -r 23:30 file:///tmp/repos/trunk/vendors现在这不是杀手er，但是如果您忘记了它是23-30包含式还是23-30包含式，或者您是否已经合并了其中一些提交，就变得无所适从，必须找出答案以避免重复或丢失提交。如果您分支了，上帝会帮助您。有了git，它只是git merge，而这一切都是无缝进行的，即使您选择了几次提交或完成了许多梦幻般的git-land事情。