在阅读如何和/或为什么在 Git 中合并比在 SVN 中更好？ 我还是不明白。假设我要维护多个版本（我需要全部维护它们，全部在生产中）：
现在我向 v1.0 提交了一个错误修复（并且我需要在所有下一个版本中修复这个错误）。
现在在 git 和 svn 中我必须执行以下逻辑操作
为此（或 gerrit）使用 git 的主要好处是什么？merge into next branch , commit , test的逻辑操作是一样的！那么有什么不同呢？（如果只是轻微的合并算法改进，那对我来说没关系。我在 Subversion 中有一个相当不错的自动合并解决冲突。我也不介意检查分支 v1.1 以在 subversion 中进行合并，因为我有一些实用程序可以为我做这件事，所以我没有花时间在它上面）。
因为 git 不像其他版本控制系统那样存储增量，它在每次提交中存储每个文件的全部内容（以一种非常压缩和高效的方式，但为了保持简单，请记住它不store deltas，抱歉重复一遍，但这就是为什么大多数刚接触 git 的专业人士会如此困惑）。
并且当它必须合并时，在每个分支的最后状态/快照和公共基础祖先之间进行三向合并，而不是尝试将一个分支的最后 100 次提交的增量/差异（具有更改的上下文）应用到另一个分支。
方法更简单，而且更有效，它不会给用户留下 100 个冲突。
我认为在比较 SVN 和 Git 的责备功能时可以证明这一点。我的公司使用 SVN（我对此很不满）。我们的开发人员不会自己进行合并，因此代码总是由不同的人合并。我经常被问到“谁改变了那条线，为什么？”。所以我执行了一个svn责备。如果该行来自另一个分支的合并，则显示的提交是合并的提交，而不是编辑该行的人。所以我必须找到那个分支并试图指责它。在上面的示例中，如果您从 v1.4 开始跟踪，您可能会浪费半天时间回到 v1.0 来查找更改。
Git blame 总是给你做出改变的人的承诺，因为这就是我们想要找出的。这对于问责制要好得多。
我认为这就是“svn 没有合并和分支的概念”的意思。它只看到合并发生时所做的提交，并且不能更进一步地追溯历史以进行适当的责备。
尽管您所做的看起来相同，但不同之处在于 git 能够在所有此类步骤中本地跟踪您要合并的内容。因此，当您更新“v1.4”时，您可以看到错误修复最初是针对 v1.0 完成的，然后合并到 v1.1（以及由谁和如何），然后到 v1.2、v1.3，最后v1.4。
svn 本身没有合并和分支的概念，v1.4 中的最终产品将只是另一个恰好更改内容“branches/v1.4”目录的树修订。最近的 svn 版本试图通过某种方式跟踪给定的修订版实际上合并了来自另一个分支的更改来解决这个问题，但这是后来内置的东西，它不能很好地工作。
另一个重要的区别是，当我测量你提到的过程需要多长时间时，我们在两个分支中进行了一个简单的更改（那时它们已经完全不同了），使用 svn/svnmerge 需要半小时，使用 git 需要 11 分钟*。这可能与 svn 需要从远程服务器获取所有历史信息这一事实有关，而 git 在本地和本机（=高效）数据结构中拥有一切。
（*这是带有运行测试等的整个工作流程。就其本身而言，svn merge 和 git merge 命令的时间差为 1.5 分钟与 <1 秒。）