Really, a concrete example that merging in Git is easier than SVN?

Question

Stack Overflow question How and/or why is merging in Git better than in SVN? is a great question with some great answers. However none of them show

Answer 1

The most concrete example I can think of is the simplest merge that does not result in merge conflicts. However (TL;DR) with that example Git is still inherently a simpler procedure than with Subversion. Lets review why:

Subversion

Consider the following scenario in subversion; the trunk and the feature branch:

   1  2  3
…--o--o--o              trunk
          \4  5
           o--o         branches/feature_1

To merge you can use the following command in subversion:

# thank goodness for the addition of the --reintegrate flag in SVN 1.5, eh?
svn merge --reintegrate central/repo/path/to/branches/feature_1

# build, test, and then... commit the merge
svn commit -m "Merged feature_1 into trunk!"

In subversion merging the changes requires another commit. This is to publish the changes that the merge did with applying the changes on the feature branch virtual directory back into the trunk. That way everyone working with the trunk can now use it and the revision graph looks like sort of like this:

   1  2  3      6
…--o--o--o------o       /trunk
          \4  5/
           o--o         /branches/feature_1

Lets see how this is done in git.

Git

In Git this merge commit is really not necessary as branches are glorified bookmarks on the revision graph. So with the same kind of revision graph structure it sort of looks like this:

         v-- master, HEAD

   1  2  3
…--o--o--o
          \4  5
           o--o

              ^-- feature_branch

With the head currently on the master branch we can perform a simple merge with the feature branch:

# Attempt a merge
git merge feature_branch

# build, test, and then... I am done with the merge

... and it will fast-forward the branch over to the commit where feature branch is pointing at. This is made possible because Git knows that the goal of the merge is a direct descendant and the current branch only needs to take in all the changes that happened. The revision graph will end up looking like this:

   1  2  3  4  5
…--o--o--o--o--o
               ^-- feature_branch, master, HEAD

The changes does not need a new commit as all git has done is to move the branch references further up to the front. All that is left is to publish this to the public repository if you have any:

# build, test, and then... just publish it
git push

Conclusion

Given this simple scenario you can assert two things in the difference between Subversion and Git:

• SVN requires at least a couple of commands to finalize the merge and forces you to publish your merge as a commit.
• Git only requires one command and does not force you to publish your merge.

Given this to be the most simplest merge scenario it is difficult to argue that subversion is easier than git.

In more difficult merge scenarios, git also provides you the ability to rebase the branch that produces a simpler revision graph at the cost of history rewriting. Once you get the hang of it though, and avoid publishing history rewrites of things already published, it isn't really that bad of a thing to do.

Interactive rebases is outside the scope of the question but to be honest; it enables you the ability to rearrange, squish and remove commits. I wouldn't willingly want to switch back to Subversion as history rewriting is not possible by design.