After reading How and/or why is merging in Git better than in SVN?
I still don’t get it. Let’s say I have multiple versions I’m maintaining (I need to maintain them all, all in production):
- v1.0
- v1.1
- v1.2
- v1.3
- v1.4
Now I commit a bugfix to v1.0 (and I need this bug fix in all next versions).
Now in both git and svn I have to perform the following logical operations
- x=1
- merge into next branch v1.(x)
- check everything is ok (tests, build) for v1.(x)
- x++ goto (2) until at last branch
What is the major benefit of using git for that (or gerrit)? The logical operations of merge into next branch, commit, test are the same! So what is different? (If it’s just minor merge algorithm improvements, it does not matter to me too much. I have a rather nice automatic merge resolve conflicts in Subversion. Also I don’t mind checking out branch v1.1 to do the merge in subversion because I have some utility that does that for me so I invest no time in it).
Because git doesn’t store deltas like other version control systems do, it stores the full content of each file in each commit (in a very compressed and efficient way, but to keep the things simple, just keep in mind that It doesn’t store deltas, sorry to repeat but this is why most professionals new to git get so confused).
And when it has to merge, makes a three way merge between last state/snapshot of each branch and a common base ancestor instead of trying to apply the deltas/diffs (with changed contexts) of the last 100 commits of one branch into another.
Way simpler approach, and it’s way more effective, it doesn’t leave the user with 100 conflicts.