開發場景
面向trunk開發
比如4人開發團隊 每2人負責一個功能模組，兩個功能模組在同一個專案中，此時如果4個人都是在主分支trunk上進行開發 那麼必須等兩個功能模組全部ok 才能上線 （操作比較簡單 不進行贅述）
缺點：
- 開發耦合性過大
- 專案程式碼不易管理
面向branches開發
分支開發 對trunk進行分支開發 按照上面的邏輯 新建兩個分支，2個人編輯一個分支 ，當其中一個分支開發完成 可以直接釋出 另外兩人開發完成後再發布
優點：
- 減少團隊作業之間的耦合性
- 程式碼管理更加方便
svn使用流程
流程圖
步驟詳解
開發過程
-
針對trunk進行 branches or tag的操作 建立新的分支 命名比如：
20180822_test_demoproject 規則：時間_功能模組__專案名稱
-
將新建的分支 checkout 至本地
-
開發新的功能 並做本地測試 （這個過程會有多次commit）
-
本地測試完成 將程式碼提交到svn 對應的branches上面
-
在beta伺服器上面進行釋出branches的程式碼並進行測試
準備釋出過程（同步trunk）
在開發過程中 trunk可能已經被別的小組修改 所以此時需要同步trunk程式碼
- 使用本地branches作為工作空間 merge from trunk 將trunk上面新增的程式碼 merge到本地 （此時本地branches中的程式碼是最完整的）
- 將新增的程式碼 提交至svn branches （此時可以進行一次beta上面的迴歸測試）
review程式碼 釋出
此時如何進行程式碼的review是一個問題 比如在3的步驟中 進行了多次提交 開發者已經不知道在開發新功能的時候提交了哪些程式碼 此時如果貿然進行釋出 可能會出現一些意想不到的情況 比如修改了配置檔案 沒有修改回來 會導致線上出現很大的問題， 那麼如何進行程式碼的review請看下面的步驟
- 將svn trunk上的程式碼checkout至本地 merge from svn branches 此時相當於將branches中的這個功能模組所有的新增或者修改的程式碼 merge到了本地的trunk上面
- 此時進行commit 在提交之前 一定記得仔細review每一個提交的程式碼檔案 是否正確 review完成確定沒有問題再提交 這一步為重中之重！！！ 不可省略，切記！
有不足之處還望不吝賜教 歡迎關注
未經作者允許 請勿轉載，謝謝 :)