我使用Git已经有一段时间了,最近有人问我为什么它的合并和分支功能比SVN更好。几年前,当我使用SVN时,我发现分支和合并非常麻烦,而且容易出错。结果,我几乎没有分支。然而,就在上周,我尝试了新的SVN1.8版本,我发现它做的非常好。
实际上我尝试了一些复杂的分支方法,没有发现有趣的错误。当然,速度非常慢,但我主要关心的是功能性,而不是速度(至少在试图说服某人时)。
所以我的问题是,SVN v1.8和Git的分支/合并功能有多大不同。特别是,我还想知道是否有一些分支和合并操作(或工作流)可以用Git完成,但不能用SVN完成(或者可以用SVN完成,但很困难)。
谢谢。
最佳答案
理解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+服务器和客户端。
希望有帮助!