SVN v 1.8分支/合并与Git相比如何？

Question

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

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

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

感谢。

Answer 1

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

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

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

如您所述，Subversion合并支持正在逐步改善。它在1.5之前根本没有合并跟踪，在1.8中取得了巨大的飞跃，即将到来的1.9将改善重命名/移动跟踪。未来还有关于“本地货架”的讨论。

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

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

总结：

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

希望有所帮助！

Answer 2

有几件事情浮现在脑海中。

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

我相信还有更多。