从 SVN 迁移至 Gitlab + Gitflow 总结

最新推荐文章于 2025-07-01 15:24:02 发布

原创

最新推荐文章于 2025-07-01 15:24:02 发布 · 2.4w 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#svn #gitlab #源代码 #gitflow

本文介绍了从SVN迁移到Gitlab并采用Gitflow工作流的实践经验，包括背景、业务分层、Gitflow概念、Gitlab的权限管理、迁移过程以及遇到的问题和解决方案，旨在提升多人协作的效率和代码管理质量。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

从 SVN 迁移至 Gitlab + Gitflow 总结

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

背景

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

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

业务分层

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

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