git - 与 Git 相比，SVN v 1.8 分支/merge 如何？

Question

我使用Git 有一段时间了，最​​近有人问我为什么它的 merge 和分支能力比SVN 好。多年前，当我使用 SVN 时，我发现分支和 merge 是相当繁琐且容易出错的操作。结果，我几乎没有分支。然而，就在上周我尝试了新的 SVN 1.8 版本，我发现它做的事情非常好。

我实际上尝试了一些复杂的分支，但没有遇到任何有趣的错误。当然，它非常慢，但我主要关心的是功能，而不是速度(至少在试图说服某人时)。

所以我的问题是 SVN v1.8 和 Git 分支/merge 功能有多少不同。特别是，我也很想知道是否有一些分支和 merge 操作(或工作流)可以用 Git 完成但不能用 SVN(或者也许可以用 SVN 完成，但它非常困难)。

谢谢。

Answer 1

了解 Subversion merge 引擎使用的模型很重要。它与 Git 非常不同。

Subversion 支持两种基本类型的 merge 。第一个是“同步” merge ，用于使开发(功能/任务/主题)分支与主干保持同步。第二个是“重新集成” merge ，用于将完成的工作提升到主干。所以该模型是一个支持特性分支和发布分支的主线(主干)模型。

一个重要的限制是 Subversion 在搜索 merge 历史以找到正确的 merge 基础时不考虑完整的 DAG。直接相关(父子)分支之间的 merge 得到了很好的支持，但是在远祖或 sibling 的分支之间进行的 merge ，以及来自其他分支的间接贡献，通常会产生令人惊讶的结果。

如您所述，Subversion merge 支持正在随着时间的推移而改进。它在 1.5 之前根本没有 merge 跟踪，在 1.8 中取得了巨大飞跃，即将到来的 1.9 将改进重命名/移动跟踪。 future 也有关于“本地货架”的讨论。

(顺便说一句，我知道其中的一些，因为我上周参加了 Subversion/Git Live session ，在 merge 引擎上工作的提交者做了一个演示。)

另一方面，Git 有一个非常受人尊敬的 merge 引擎。它可以处理几乎任何复杂性的 merge 。事实上，它唯一的主要 merge 限制是它在事后推断移动/重命名。在非常复杂的重构情况下，它可能无法正确选择所有内容。

总结:

• Subversion 和 Git 在常见的 merge 场景中都能很好地工作。
• Git 将更有效地处理更复杂的 merge 场景，尤其是在没有直接父子关系的分支之间进行 merge 时。
• 这两个系统在重构过程中都无法跟踪重命名/移动，尽管 Git 在典型情况下可能做得更好。
• Git 的 merge 命令在简单的情况下更容易运行。如果您要执行不寻常的操作，这两个系统的学习曲线都会很陡。
• Git 支持相关操作，例如在存储库之间进行 rebase 和 merge ，在某些情况下可以改进您的工作流程。
• 要充分利用 Subversion，请确保您拥有 1.8+ 服务器和客户端。

希望对您有所帮助!