1. 问题背景
我在上一家公司时，一直用的是 SVN，一开始还好，主项目拆分改造成微服务时，本地项目多到那叫一个恶心啊！
我现在手上自然是不可能有以前公司的分支。但是我自己照着印象建了几个文件夹，给你们感受一下：
1.1 外层：工作目录
- DevBranch 存放的是开发分支，这个由项目经理从 ReleaseBranch 切出。我当时作为一名朴素的CRUD工程师，这也是我接触最多的一套分支。
- TestBranch 存放的是测试分支，由测试人员从开发分支中切出。主要担心测试过程中，开发人员“悄悄”提交代码，所以测试环境都是发布的这套分支上的代码
- ReleaseBranch 存放的是发布分支。产品上线后，最后一次被测试人员测试的开发分支代码将被合并到发布分支。
1.2 DevBranch：开发分支
我一般会同时负责多个版本中多个小功能的开发，所有一般各个分支都会切下来。
我一般都不敢随便把本地分支删除。项目经常是交叉进行的，如果出现了线上问题，那我需要：
- 重新从 SVN 远程仓库获取分支;
- 重新用 IDE 打开项目;
- 重新配置 Configuration... 才能启动起来。
就算一切顺利，一般折腾一次也要 5min。
项目微服务化后，主项目拆出来很多子项目，折腾一下少说 15min，多则 1h，我就不敢乱删本地分支了。
1.3 微服务项目
现在想想，其实也可以采用 Maven 项目中多个 Module，每个 Module 作为一个微服务的那种结构。不过那也仅是“抱薪救火”，因为你开发一个新的版本时，你还是至少要 Check 一次新的分支代码。
但是当时微服务的框架是从以前的主服务框架里面稍加修改演变而来的，所以就没有采用一个 Maven 项目多个 Module 那种结构。
假如开发一个版本 V_1.0.3 至少要且 User，Order，Inventory，Gateway 这几个微服务下来，才能正常测试一个较为完整的业务链。
那么，所有相关系统的代码，我都需要全部从 SVN 远程服务器下载下来。而且我们当时的微服务项目数量好像是 10+。
2. 角色与处境
据我所知，目前我的上一家公司，还是这样进行版本管理的：
-
架构师：受一定影响，但是影响没那么大，因为只有明确有线上问题需要架构师来定位时，他才需要切分支
-
项目经理：我们的项目经理使用 SVN 这套工具已经 8 年多了，而且他现在已经不参与一线的编码工作了。要让他迅速切换到 Git，他不熟悉。
而且 SVN 切分支和合并分支对他而言，还不算特别麻烦。切换 Git 时的学习成本和“切换风险”，使得他推动 SVN 升级到 Git 的主观意愿并不强烈。 -
运维工程师：以前根据 SVN 方式部署了一套能够自动发布的 jenkins 环境，如果改用 Git 方式，是需要修改 Shell 和调试环境的，具体需要多少人力，我不清楚。
-
CRUD工程师：如果你好巧不巧正在经历着这些，其实你是什么都改变不了。
每一个版本，你都需要切 N 个分支，用 IDE 打开 N 次项目，配置 N 次 Configuration，然后 Close Project，再切 N 个分支，周而复始。
3. 如果是 Git
如果使用的是 Git，那么恭喜你，你的 WorkSpace 有且仅有这些
你只需要用 IDE 打开一次，配置一次 Configuration... ，然后就可以享受编码了。
这篇文章只是前置篇章，我接下来写一篇博客聊一聊 CRUD 工程师如何用好 Git 这一神器，敬请期待。
4. 建议
假如你是架构师和项目经理和老板，恰巧看到了这篇文章，我就替那些“绝望的”CRUD工程师们，我求求你了，推动一下 SVN 向 Git 全面切换吧。
个人感觉，这也是从单个项目升级到微服务项目时，应该要做的事情之一。
我对 SVN 没有什么深入研究和实践，所以这里只是把以前的解决方案给大家展示一下。如果有把 SVN 用得更好的朋友，欢迎在评论里面给我批评指正。