一、使用svn遇到的问题

从参加工作至今，一直使用svn作为代码版本工具，基本能够满足日常工程开发过程中的代码版本管理需求，直到维护目前的线上运行的项目。

场景一：

完成一个版本的开发后，例如3.0版，在svn上标记一下当前版本，团队继续开发版本4.0。过几天后发现线上的bug1，这时候从哪个版本的代码修复bug1，有两种选择，一种是直接在4.0的开发代码上改，尽量把代码还原到3.0时的状态，再修改bug1；另一种选择是从svn标记的版本检出进行修改。这两种方法都尝试过，但问题是过几天再出现bug2，没有地方能找到3.0版+bug1修复的代码，bug2修复遇到困难。

场景二：

随着平台3.0版本的发布，需要长时间开发大版本的需求减少，零碎的小需求增多。如果把小需求都拖到大版本一起上线，会对平台运营产生影响。因此，小版本迭代和大版本开发的同时进行，将成为未来一段时间团队的矛盾点。而与此同时，如何能管理两个并行版本的代码，对svn来讲几乎无解。

二、尝试更换git

通过在网上的简单了解，git版本库拥有分支管理的功能，似乎可以解决svn使用过程中的问题，决定在团队内部进行小规模的尝试。

经过配置管理同事的努力，在公司内网搭建了gitlab服务，开始git之旅。

首先在iOS和安卓开发团队进行了试点，初步确定了以人为单位打分支，每人每天下午下班前提交代码到自己的分支，全部提交后由团队负责人把代码合并到master分支。

这种方式进行了一个版本的开发，也没出什么乱子，仿佛git就是一个复杂版的svn，直到把git推广到后台开发团队。

三、问题出现

当后台也开始使用git后，开始出现奇怪的问题，当多人的开发的分支合并到master时，开始出现代码混乱，偶尔操作不规范时还会引起代码的丢失。

另外，由于后台开发成员要多于客户端的开发成员数，每天的代码分支合并，会成为后台负责人的一项工作负担。

之所以在后台团队开始使用git后出现这些问题，主要原因还是客户端开发人数少，每个端（工程）两个人维护，以人为单位打分支的弊端并没有被发现。

四、新思路

出现问题后开始寻找解决办法，在网上看到一个说法，引起了我的思考：master分支保持和线上版本一致。

那么，是不是可以尝试多人共用一个远程分支？模拟了一下在两台开发机器上使用同一个远程分支的各种情况，事实证明可行。

多人共用一个远程分支时，和使用svn的效果是相似的（不相同，这里不展开说）。

既然多人可以共同使用一个远程分支，是不是可以以版本为单位打远程分支？

五、解决方案

以平台实际的版本开发，推演了一下新思路，平台要在三个月后上线4.0版本，那么打一个4.0dev分支。

三个月期间需要上线三个小版本，分别是3.1、3.2、3.3，由于三个小版本按顺序开发，所以只使用一个远程分支即可。

这时候一共有三个分支master、4.0dev、3.1dev，需要开发对应版本的同事，克隆对应版本的分支即可。

当3.1版本开发完成，经过测试上线后，首先将3.1dev的分支合并到master分支，这样就保持了master分支和线上代码一致。合并后，4.0dev分支从master 拉取代码，拉取成功后（有冲突，解决过程不展开说），4.0dev分支就实际包含了3.1已发布的代码和4.0正在开发的代码，完美实现了版本的过度。

六、小惊喜

无意间发现sourcetree的一个功能，分支切换。可以把本地工作副本关联到多个远程分支，需要时双击切换到对应的分支，并刷新一下开发环境即可。

这让一个人参与多个分支的开发，变得十分便捷。

七、线上问题修改

解决了版本分支的问题，解决线上问题也变的很轻松。打出一个bug修复分支，在分支上修改代码，经过测试后代码发布到线上环境。发布成功后合并bug修复分支到master分支，合并后各个开发分支再从master把代码拉取到本分支。

写在最后

经过两个版本的摸索，整个团队完成了从svn到git版本库的过度。过程中经历过不少困难，遇到过很多的阻力，冒着代码丢失和进度无法推进的风险，最终还是成功的完成了这一步。

快速版本迭代成为可能。