Svn在工作中的实践感悟

时间:2020-12-20 11:16:09

Svn是一款管理项目代码的版本控制系统,是基于集中式的版本控制系统。在工作中,由于实际开发工作的需要,部门是使用Svn来管理日常的项目开发任务。使用这么长时间了,来谈谈对Svn的感悟。

首先,说下工作流程。根据实际的需求,将整个项目流程分为四部分:本地,ft,uat和正式环境。本地主环境要是提供给员工在开发测试使用的,是在个人电脑上进行的,ft环境是测试人员进行测试场所,uat环境是预发环境,一般是给产品使用,而正式环境就是线上啦。

在每个环境下,包括多个文件夹,每个文件夹下是一个具体的项目,它们共用一套php框架(Thinkphp框架)。由于公司业务繁忙,因此开发人员多大数十个。平时除了开发新的任务外,还必须维护旧的代码和旧平台的快速迭代任务。在使用的过程中,觉得Svn版本控制系统,最大的优点就是能够集中管理项目代码,控制权限分配。针对不同级别的开发者,赋予不同的权限,这样可以避免代码提交的混乱,管理好项目代码,确保开发工作的正常进行。但也有问题存在。最典型的就是,由于是集中式的管理,大家提交的代码merge,commit到master时,类似于一条直线(针对同一个项目来说),不能跳过merge,这样在合并代码的时候就会出现冲突。举个栗子说明。我在A项目下的B文件中进行新任务的开发,然后同事C接到Boss命令,说A系统出现了问题,需要去fix。正好,出问题的地方在B文件下(同文件下不同地方)。那么就会出现一种很尴尬的情形:由于我的代码是在C之前提交到ft上的,还在被测试。而C修改的代码需要紧急上线,修补线上问题。在merge代码时,要不,就直接把我的代码也一并merge,然后commit,要不就忽略掉我的这个版本。如果先合并C的版本,而我的版本不管,二者就会产生冲突。由于开发者多,有很大概率会遇到这个问题。所以boss在合并代码时,经常要协调我们解决冲突。那么,有没有什么办法来解决呢?答案是有的。

那就是Git版本控制系统,它是基于分布式的版本控制系统。将项目代码分为master分支, dev分支,fix分支(为方便说明,暂分为三个分支)。master分支属于主线,只能合并代码,线上使用。dev分支就是日常开发者使用,大家日常项目开发,任务迭代均在此分支下。fix分支专门用来解决线上bug问题的。平时开发,dev分支进行,测试无误后,merge到master分支。如果线上出问题了,就在fix分支进行,修改完成,然后merge到master分支上即可。fix分支不会影响到dev分支,避免了冲突