从 SVN 迁移至 Gitlab + Gitflow 总结

从 SVN 迁移至 Gitlab + Gitflow 总结

转载请注明出处http://blog.csdn.net/uxyheaven/article/details/50373076

背景

之前在的公司一直都是用svn做源代码管理, 人少的时候也木有发现什么太大的弊端. 后来换了一个团队后, 业务发展速度实在是超乎想象.
短短的几个个月时间, 我们单语种的开发人员扩充到了10人以上, 接下来的两个月中, 人数要到20人. 我们的并行版本也是增加了好几个. 有的版本是由于特殊原因, 一直木有发版, 并行了几个月(代码也就是一直木有同步了…); 有的则是业务线的开的多, 就是需要同时开很多个分支, 一个分支一个版本, 在发版的时候在合并起来.

在这期间, 我们次次发版前的合并代码是一项艰巨的任务. 既然代码管理已经是个问题了, 那么就需要改了.

业务分层

业务层的代码只要不涉及到其他业务模块, 总是相对独立的.
我在刚来的时候先横一刀斩出了业务层. 从物理目录上隔离了业务模块代码和其它代码. 再竖几刀切出了各个业务模块. 虽然代码还是原来的代码, 不过最起码物理文件夹不一样了, 合并代码的时候再不济直接整个文件夹替换便是.

然而事实证明我是too young, too simple. 如果次次的代码变动只是业务层, 理论上也不会有啥冲突. 问题是出在我们的业务发展太迅速, 我们的业务代码以外的其它代码也是动不动就不能满足需求了, 需要随着业务代码的改变而改变. 这就导致了业务A为了满足自己的需求直接就改了其它代码成PPAP, 然后业务B为了满足自己的需求改了其它代码成PPBP, 嘛, 冲突就这么来了.

Gitflow

俗话说没有经历过业务高速发展的架构师都是扯淡. 很庆幸我们团队能有这次机会随着业务一起成长