分支允许您的团队同时处理多个版本的代码。开发人员可以测试新功能,而不会因错误和异常而影响开发的其余部分。当新功能稳定时,分支将进行合并。

Subversion(SVN)中,分支只是一个名称。合并SVN分支可能非常耗时且局限。开发人员必须手动解决冲突,这可能会对功能交付产生重大影响。

颠覆分支策略

关于SVN最常见的抱怨是它繁琐的分支和复杂的合并模型。SVN分支创建为存储库中的目录。这个目录结构是SVN分支的核心痛点。每个开发人员需要更多的时间成本。

SVN分支如何工作

以下是SVN分支的工作原理。SVN的“分支”目录与“trunk”目录并行运行。SVN分支复制主干并允许您进行更改。

分支策略:分支之间的关系

分支之间的关系和分支与主干的关系在SVN中不是那么简单的存在。开发必须提出命名方案或创建外部文档。但是这种Subversion分支策略并不是最优的。

分支策略:合并变更

当您在您的分支工作时,偶尔会从主干到您的分支进行合并,以使您的目录保持最新状态。每次发生这种情况时,都会将复制更改并归并到您的分支目录中。这可能会也可能不会反映其他开发人员的变化。

分支战略:并行开发

当分支整理完成后时,您会将内容提交到主干。当然,你不是唯一合并这些内容变化的人。您的主干版本可能不会即时反映其他开发人员的分支情况。这意味着冲突,丢失文件和混乱的变化让你的分支变得混乱不堪。

让我们仔细看看这个例子。

1.0 trunk有两个开发人员在单独的版本上工作。当正在处理1.4和2.0 dev分支时,它们将从主干到dev分支合并以收集更新。

并行SVN开发对其他分支的可见性有限。当1.4 dev分支与主干合并时,它会被推送到开发中。这可能发生在最小冲突的情况下,但对于2.0 dev分支也是如此。

分支策略:解决树冲突

长期存在的分支存在更大的问题风险。SVN不会告诉您分支在主干上的位置。您必须梳理代码以确定它所属的位置以及缺少的更改。当对目录结构进行更改时,通常会发生树冲突。重命名或删除文件时可能会发生这种情况。由于这些变化非常普遍,您将会搜索一段时间。

由于在发生树冲突时无法提交更改,因此必须手动解决每个错误。即使使用“合并跟踪”,您也可能无法确定分支中缺少哪些更改。这可能会严重延迟部署。此外,随着团队规模的扩大,分支可能变得不那么稳定,难以维护。

如何解决SVN分支问题

很明显,SVN分支和合并是一个问题。 Helix Core提供了一种强大而简单的分支方法:Streams。开发人员可以使用任务流来处理项目的一小部分,而不会影响生产或其他开发人员

Streams定义了每个分支的目的:主线,开发,任务或发布。它们遵循主线模型,所有更改都流向主线,类似于SVN主干。它允许开发人员专注于他们的代码 - 而不是分支和合并。Stream Graph创建分支层次结构的图形表示。这意味着您的团队始终知道每个人都在做什么。Streams的独家签出和细化权限可以建立更多的变更可见性。

这种流策略解决了SVN分支的许多问题。

在Helix Core中,没有固定的命名方案。Helix Core使用单独的数据库表来跟踪每个合并。跟踪分支的变化有很多种方法:修订历史记录,时间间隔视图和修订图表。

了解有关从SVN迁移到Helix Core的更多信息>> https://www.perforce.com/resources/vcs/why-svn-users-are-migrating-helix-core 

尝试一下Helix Core https://www.perforce.com/products/helix-core/free-source-control 

原文链接: https://www.perforce.com/blog/vcs/svn-branching-and-merging