软件开发版本策略

软件开发版本策略

前言

目前主流的版本管理工具主要是svn和Git，也有部分大公司用ibm的cc，以前在国有银行工作的时候用过cc，感觉特别笨重，功能特别复杂，用户体验特别差，总之用过的都不想再用，今天主要介绍下日常软件开发中的版本策略的话题，因为最近在新公司发现很多开发人员都没有版本的概念，对于版本分支、baseline、标签都没有概念，今天就借这篇文章给大家普及下，大神请绕过本文普及贴。

1. svn常用版本策略

说到svn大家用的比较熟的工具应该是Tortoise小乌龟了，svn是典型的集中式版本管理工具，目前大部分的管理工具也都是集中式。说到版本策略主要就是开发和发版策略，使用svn的话，主要有两种版本策略。

一种是把trunk主干分支作为迭代开发使用的分支，所有人当前开发的代码都提交到该trunk分支上，一旦版本稳定进入测试阶段则以当前的trunk开发分支作为基准拉一个发版分支release1，一旦在测试过程中发现bug就在trunk开发分支开发测试完提交修复的代码，再将代码merge到release1分支，到测试完毕没有问题了就讲release1分支打上tag提交发版，该种分支策略比较简单，一般适用于跨迭代比较少的情况，串行实施会比较简单，版本策略也比较清晰。但是一旦遇到多版本迭代开发，大量任务跨迭代开发就会导致trunk开发分支非常混乱，无法承载多任务并行开发，如果是任务影响的代码没有重叠还好，一旦有多个批次的不同任务影响到一样的代码那么就会存在问题，就需要开发人员自己在本机保存代码，等自己开发任务的上个版本发版后才能提交到svn，不然会影响到之前版本的发版。

所以，对于版本重叠比较多的情况，一般会采用下面介绍的这种策略，trunk主干分支作为比较稳定的分支，只有发版或者修复生产bug后才会merge到trunk主干分支，当进入一个新迭代由版本管理员基于trunk创建一个dev1开发分支，所有涉及到该迭代的开发人员都在dev1分支上进行开发工作，当dev1还未发版，有其他任务插入则再在trunk上拉出dev2分支，涉及任务的开发人员在dev2上进行开发，一旦dev1迭代的任务进入测试阶段则在dev1分支基准上单拉一个uat1分支，测试阶段的任何bug都是在dev1分支上开发完后再merge到uat1分支，让测试进行校验，当要发版则在uat1的基础上打上tag就可以发版了，发版后需要将代码merge到trunk主干上，这时dev2的代码还未发版，所以还需要将trunk主干分支代码merge到dev2上，保证dev1的代码包含进了dev2，这样操作起来虽然比较麻烦，但是能够很好的保证多版本迭代的情况，让代码分支结构清晰，但是对项目经理和版本管理员的要求较高，而且存在大量的merge工作，对团队开发人员的能力也有一定的要求。总结下来第一种版本策略适合小型互联网公司的快速小迭代开发，省去了很多版本merge的工作，第二种适合大型公司的多版本同步开发方式。

2. Git常用版本策略

对于使用了很多年svn的同学刚开始接触Git的时候很难短时间接受，可以一旦上手以后就会爱不释手，会发现其中的很多优势。下面介绍下Git的常用版本策略。

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在单拉的dev分支上，也就是说，dev分支是不稳定的，到某个时候，版本发布时，再把dev分支merge到master上，在master分支发布版本，并打上Tag；
团队中的每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。这时你可能会说了，如果有多版本迭代怎么办，其实总体思路和svn第二种差不多但是实现起来会简单很多，在dev版本还未发布的时候又有了新的开发任务那么从master分支上checkout一个新的dev2分支，所有新任务都在dev2上开发，也是每个相关人员都再拉一个自己的分支进行开发，定期merge到dev2分支上，当dev发版后将dev的代码merge到master上，此时dev2上开发同学，需要将master上最新的发版代码再pull到本地，这样dev2分支代码也是dev发版后的最新稳定代码，并且包涵了dev2上开发的new feature。是不是比svn用起来要简单很多。

3. svn、Git版本管理对比

Git分布式版本控制系统与svn集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

Git对比svn最大优势不仅仅是分布式，更大的优势就是上面介绍的分支管理，可以很方便的拉分支，合并代码，建议还没使用Git的团队可以尝试下Git，Git使用起来还是很方便的，而且linux、mac电脑都是自带git，通过命令行就可以进行git操作，使用起来也是很方便。但是整个团队从svn迁移到Git还是有一个阵痛期的，过了阵痛期会感觉到版本迭代效率非常高，版本管理会更加灵活。