SVN 和 Git 合并的区别是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2692950/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's the difference between SVN and Git for merging?
提问by Alexander
As the title suggests, I am curious as to why so many people tout Git as a superior alternative to branching/merging over SVN. I am primarily curious because SVN merging sucks and I would like an alternative solution.
正如标题所暗示的那样，我很好奇为什么这么多人吹捧 Git 作为分支/合并优于 SVN 的替代方案。我主要是好奇，因为 SVN 合并很糟糕，我想要一个替代解决方案。
How does Git handle merging better? How does it work?
Git 如何更好地处理合并？它是如何工作的？
For example, in SVN, if I have the following line:
例如，在 SVN 中，如果我有以下行：
Hello World!
你好，世界！
Then user1 changes it to:
然后 user1 将其更改为：
Hello World!1
世界你好！1
then user2 changes it to:
然后 user2 将其更改为：
Hello World!12
世界你好！12
Then user2 commits, then user1 commits, SVN would give you a conflict. Can Git resolve something simple as this?
然后 user2 提交，然后 user1 提交，SVN 会给你一个冲突。Git 能解决这么简单的问题吗？
回答by VonC
That is called on merge with conflict, and no VCSwill ever solve that for you.
You will have to manually solve the merge yourself.
这就是所谓的合并冲突，没有VCS会为你解决这个问题。
您必须自己手动解决合并问题。
As mentioned in Why merging in git is better than SVN, the actual difference is in the history recording of commits:
正如为什么在 git中合并比 SVN 更好，实际区别在于提交的历史记录：
- linear for SVN
- DAG (Directed Acyclic Graph) for Git
- SVN的线性
- 用于 Git 的 DAG（有向无环图）
That allows Git to remember what has already merged, reducing considerably the conflicts occurrences.
这允许 Git 记住已经合并的内容，从而大大减少了冲突的发生。
So, when it comes time to do merge from 5b over to the (a) branch, we can use information in the DAG to know that 3b and 2b are already done
因此，当需要从 5b 合并到 (a) 分支时，我们可以使用 DAG 中的信息知道 3b 和 2b 已经完成
So it is the merge workflowthat Git will handle much more gracefully than SVN:
See Merge Git vs. SVNfor concrete examples.
因此，Git 将比 SVN 更优雅地处理合并工作流：
有关具体示例，请参阅合并 Git 与 SVN。
回答by Cascabel
The specific conflict you mention is alwaysunresolvable. There's simply no way for a merge tool to know which version should be kept.
您提到的具体冲突始终无法解决。合并工具根本无法知道应该保留哪个版本。
Git is probably better than SVN at dealing with resolvable conflicts, though. Its primary merge strategy is recursive, which finds the common ancestor of two commits changing the same file and does a three-way merge. It also has some built-in capability for recording and reusing conflict resolutions (git-rerere) and a variety of other merge strategiesfor special cases.
不过，在处理可解决的冲突方面，Git 可能比 SVN 更好。它的主要合并策略是递归的，它找到更改同一文件的两个提交的共同祖先，并进行三路合并。它还具有一些用于记录和重用冲突解决方案的内置功能 ( git-rerere) 以及用于特殊情况的各种其他合并策略。
Git's advantage in merging is that it's part of the history. A merge commit is a commit with two parents. Git's model of history (a directed acyclic graph) expects there to be commits like this. This means that further merges in the future work exactly how they should. Always. (Yes, there are sometimes conflicts, but they're real conflicts, not an inability to handle the merge.)
Git 在合并方面的优势在于它是历史的一部分。合并提交是具有两个父项的提交。Git 的历史模型（有向无环图）预计会有这样的提交。这意味着未来的进一步合并将按照他们应该的方式工作。总是。（是的，有时会有冲突，但它们是真正的冲突，而不是无法处理合并。）
SVN, on the other hand, just tries to track where merges occurred, but its model is still inherently linear. The history still just has a single string of commits, with merge tracking information providing extra help. From what I've heard, SVN can't always handle more complex merge patterns correctly. (One example is a reflective merge - merging A into B then B into A.)
另一方面，SVN 只是试图跟踪合并发生的位置，但它的模型本质上仍然是线性的。历史仍然只有一串提交，合并跟踪信息提供了额外的帮助。据我所知，SVN 不能总是正确处理更复杂的合并模式。（一个例子是反射合并 - 将 A 合并到 B，然后将 B 合并到 A。）
