18

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

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

所以我的问题是 SVN v1.8 和 Git 分支/合并功能有多大不同。特别是，我也很想知道是否有一些分支和合并操作（或工作流程）可以用 Git 完成，但不能用 SVN 完成（或者它可以用 SVN 完成，但这很困难）。

谢谢。

4

2 回答 2

24

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

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

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

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

（顺便说一句，我知道其中的一些，因为我上周参加了 Subversion/Git Live 会议，并且在合并引擎上工作的提交者做了一个演示。）

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

总结一下：

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

希望有帮助！

于 2013-10-13T01:42:01.863 回答
1

有几件事浮现在脑海中。

  1. Git 支持 AFAIK SVN 不支持的私有分支。
  2. Git 积极支持团队的一名或多名成员正在开发的工作流，可能是支持或机密的分支，提交版本控制和协作，无需子团队成员之间的协作，而无需将工作“发布”给团队的其他成员，并且无需复杂的 ACL 控制来锁定某些分支，使其无法被团队的其他成员访问。
  3. 使用 git 和多个开发人员，您始终可以恢复您的存储库（或其中的大多数），并在发生故障时完成历史记录，而所有开发人员的机器都被清除 - 如果主服务器/存储库发生问题，则使用 SVN这完全取决于您的备份策略。

我相信还有更多。

于 2013-10-12T10:46:41.093 回答