Svn在工作中的实践感悟

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分支，避免了冲突