git - 如果您仍然必须执行相同的步骤，那么 git merge 比 svn merge 有何优势？

Question

看完How and/or why is merging in Git better than in SVN?我还是不明白。假设我有多个要维护的版本(我需要维护所有版本，所有版本都在生产中):

• v1.0
• v1.1
• v1.2
• v1.3
• v1.4

现在我提交了一个错误修复到 v1.0(我需要在所有下一个版本中修复这个错误)。

现在在 git 和 svn 中我必须执行以下逻辑操作

1. x=1
2. merge 到下一个分支 v1.(x)
3. 检查 v1.(x) 的一切正常(测试、构建)
4. x++ goto (2) 直到最后一个分支

为此使用 git(或 gerrit)的主要好处是什么？ merge into next branch、commit、test的逻辑操作是一样的!那么有什么不同呢？ (如果这只是 merge 算法的小改进，那对我来说并不重要。我在 Subversion 中有一个相当不错的自动 merge 解决冲突。而且我不介意检查分支 v1.1 以在 subversion 中进行 merge ，因为我有一些实用程序可以为我做这件事，所以我没有花时间在上面)。

Answer 1

因为 git 不像其他版本控制系统那样存储增量，它在每次提交中存储每个文件的完整内容(以一种非常压缩和高效的方式，但为了简单起见，请记住 < strong>它不存储增量，抱歉重复一遍，但这就是为什么大多数刚接触 git 的专业人士都感到困惑的原因)。

并且当它必须 merge 时，在每个分支的最后状态/快照和公共(public)基础祖先之间进行三向 merge ，而不是尝试应用一个分支的最后 100 次提交的增量/差异(具有更改的上下文)进入另一个。

方法更简单，也更有效，不会给用户留下 100 次冲突。