关于版本控制:版本管理-如何解决SVN的合并冲突与分支问题

7次阅读

共计 1823 个字符，预计需要花费 5 分钟才能阅读完成。

Subversion 是一种集中式的版本控制系统，个别被简称为 SVN。作为目前可用的泛滥版本控制选项之一，SVN 仍旧存在着分支性能弱、集中式导致服务器压力大等问题。

如果您的需要曾经超过 SVN 所提供的性能范畴应该怎么办？龙智将在系列文章中为您提供其余版本控制软件的实际参考。咱们将从为什么应用 SVN、命令备忘录清单、托管储存库、如何应用客户端等角度比照 Perforce Helix Core、SVN 与 Git，让您可能深刻理解各个版本控制软件的优缺点。（已公布文章可在文末【往期举荐】中浏览。）

作为 DevSecOps 研发平安经营一体化解决方案供应商，龙智继续关注版本控制畛域动静与倒退，为您进步最新洞察与最佳实际参考，帮忙大型开发团队更好地进行数字资产治理与合作。

分支和合并是开发的次要内容。然而，SVN 繁琐的分支和简单的合并模型始终备受用户诟病。本文将从 SVN 的分支与合并工作原理来剖析，并给出解决问题的方法。

首先，咱们将介绍 Subversion 的分支工作形式，以及如何应用 SVN 合并。

Subversion 分支（SVN 分支）容许您的团队同时解决多个版本的代码，开发人员能够测试新性能，不会因谬误和 bug 影响其余开发工作。

SVN 的“分支（branch）”目录与“骨干（trunk）”目录并行运行。SVN 分支能够复制骨干，并容许您对其进行更改。当新性能稳固时，分支会从新合并。

以下是 SVN 分支和合并的根本分步概述：

应用 svn copy 命令创立分支。
应用 svn checkout 签出新的工作正本。
应用同步合并可使分支在工作时放弃最新。
应用 svn merge 将更改发送回骨干。

用户对 SVN 诟病最多的是其繁琐的分支和简单的合并模型。SVN 分支作为储存库中的目录创立，这种目录构造是 SVN 分支的外围难点。它占用了开发人员大量的精力。

Subversion 分支之间的关系

分支之间的关系以及分支与骨干的关系都不易存储在 SVN 中。开发人员必须提出命名计划或创立内部文档。

并行开发中的 SVN 合并

在您在解决分支时，偶然会从骨干合并到分支，以放弃目录最新。每次产生这种状况时，都会将更改复制到分支目录中。这可能会也可能不会反映其余开发人员正在进行的更改。

当分支准备就绪后，应用 SVN 合并提交回骨干。当然，您不是惟一一个进行合并更改的人。您的骨干版本可能不会反映开发人员的分支。这意味着抵触、失落的文件和凌乱的更改困扰着您的分支。

让咱们认真看一下这个例子：

1.0 骨干有两个开发人员在不同的版本上工作。随着 1.4 和 2.0 开发分支的开发，它们将从骨干合并到开发分支以收集更新。

并行 SVN 开发对其余分支造成了无限的可见性。当 1.4 开发分支与骨干合并时，它被推送到开发中。这可能是把抵触降到最低的状况，但对于 2.0 开发分支就不一样了。

SVN 树抵触
长期存在的分支呈现问题的危险会更大。SVN 不会告诉您分支在骨干上的地位。您必须对代码进行梳理，找出它所在的地位以及短少哪些更改。

当更改目录构造时，通常会产生 SVN 树抵触，重命名或删除文件时可能会产生这种状况。因为这些更改很常见，您须要花点工夫来搜寻。

因为在产生树抵触时无奈提交更改，您必须手动解决每个谬误。即便应用“合并跟踪”，您也可能无奈找出分支中短少了哪些更改。这可能会重大提早部署。此外，随着团队规模的扩充，骨干可能会变得不够稳固，导致其更加难以保护。

很显著，SVN 分支和合并是个问题。Perforce Helix Core 提供了一种弱小而简略的分支办法：Perforce Stream。

开发人员能够应用工作流来解决我的项目的一小部分，而不会影响生产或其余开发人员。工作流定义了每个分支的目标：主线、开发、工作或公布。它们遵循主线模型，所有更改都流向主线，相似于 SVN 骨干。它让开发人员专一于本人的代码，而不是分支和合并。

分支层次结构的图形示意由工作流程图创立，这意味着您的团队始终晓得每个人在做什么。

此外，Streams 的独占签出和颗粒度的权限设置让所有都清晰可见。这种流式传输策略解决了 SVN 分支的许多问题。在 Perforce Helix Core 中，没有固定的命名计划。Perforce Helix Core 应用一个独自的数据库表来跟踪每次合并。还有许多办法能够跨分支跟踪更改：订正历史记录、延时视图和订正图。

文章起源：https://bit.ly/3AGWwtP

正文完