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 用得更好的朋友，歡迎在評論里面給我批評指正。