What's the difference between SVN and Git for merging?

Question

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.

How does Git handle merging better? How does it work?

For example, in SVN, if I have the following line:

Hello World!

Then user1 changes it to:

Hello World!1

then user2 changes it to:

Hello World!12

Then user2 commits, then user1 commits, SVN would give you a conflict. Can Git resolve something simple as this?

Answer 1

That is called on merge with conflict, and no VCS will ever solve that for you.
You will have to manually solve the merge yourself.

As mentioned in Why merging in git is better than SVN, the actual difference is in the history recording of commits:

• linear for SVN
• DAG (Directed Acyclic Graph) for Git

That allows Git to remember what has already merged, reducing considerably the conflicts occurrences.

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

---

So it is the merge worflow that Git will handle much more gracefully than SVN:
See Merge Git vs. SVN for concrete examples.

Answer 2

The specific conflict you mention is always unresolvable. 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 strategies for special cases.

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.)

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.)