项目中使用SVN管理原则

最新推荐文章于 2023-02-16 14:19:26 发布

wus_shang

最新推荐文章于 2023-02-16 14:19:26 发布

阅读量447

点赞数

CC 4.0 BY-SA版权

分类专栏：雷默 SVN

本文链接：https://blog.youkuaiyun.com/wus_shang/article/details/79286802

雷默同时被 2 个专栏收录

41 篇文章

订阅专栏

SVN

4 篇文章

订阅专栏

一、为什么需要分支

大多数产品开发存在这样一个生命周期：编码、测试、发布，然后不断重复。通常是这样的开发步骤：

1) 开发人员开发完毕某一版本（如版本A）功能后，提交测试；

2) 测试人员对待发布版本A进行测试，同时开发人员继续开发新功能(如版本B)；

3) 测试人员提交bug，研发人员修复bug，同时继续开发新功能；

4) 重复第3步骤，直到待发布版本A测试通过测试后，发布第一版本

这样就会存在以下问题：

1) 如何从代码库中(A+B)分离出待发布版本A，进行测试和发布；

2) 如果单独存放待发布版本A，那么开发组必须同时维护此版本库A以及当前最新代码库(A+B)，操作冗余且容易出错。

在SVN中，通常采用主干（trunk）与分支（branches）的方法，解决以上问题。

SVN 新建时可以选择性的建立三个文件夹：

1. trunk  ：一般作为主开发的地方

2. branches ：一般作为从trunk Copy过去的代码，形成分支

3. tags  ： 一般作为固定版本，不进行修改，此版本有bug直接拉取进行修改（可理解为打包后的版本）

二、代码的分支管理策略

关于代码管理的分支和发布策略，目前主要有两种：一种是主干作为新功能开发主线，分支用作发布。另一种是分支用作新功能开发，主干作为稳定版的发布。（可以根据自已的项目实际需要建立不同的版本管理策略）

我们项目目前的版本管理策略是第二种，分支用作新功能开发，主干作为稳定版的发布：

1）系统在没有上线之前，只有一个主干(trunk)，如果系统很简单，所有开发人员可以在主干上进行协同开发，减少合并的工作量以及冲突问题。

注意：如果系统很复杂！！！上线时可能部分功能会有未完成的情况，可为每位开发人员单独创建分支，上线前进行分支合并，防止因为一个功能未完成导致整个系统不能即时上线

2）打包测试没问题后，系统上线在主干的基础上创建一个标记（tags），如1.0，该标记主要是发布（release ）版本,是对主干代码的复制，对当前线上版本的一个标记。

3）1.0系统上线后发现一个新BUG或者紧急新功能上线，如果刚开发时用的是主干开发，这时候我们就需要用到分支了，我们在tags/1.0上创建一个分支（branches），如1.0-yxh，在分支上修改或编写。

4）编写完成后将1.0-yxh分支合并到主干上，再创建一个标记，如1.0.1。

5）循环3和4步骤.

三、最终原则

主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。

而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标记而不是分支。分支上的开发和测试完毕以后才合并到主干。

branches 与tags 的生成过程其实就是trunk 代码完整Copy过去的。 后期branches的修改或者trunk修改如果需要同步代码，需要Merge操作，即代码合并，其中需要解决代码冲突Conflict。

引用胡二勇的理解：

也就是说无论开发新功能还是修改线上的bug，这些应该是在tags上建的分支，或者从主干建的分支进行修改的，不应该在主干上直接修改，主干的代码要保证是正确的，保证是从分支合并过来的，经过测试没有bug的，而tags是每次从主干打包时，对主干代码的复制，是对当前线上版本的一个标记，以方便对线上版本bug进行修改的一个标记。