svn分支協同開發流程（內附超詳細流程圖和解釋）

開發場景

面向trunk開發

好比4人開發團隊 每2人負責一個功能模塊，兩個功能模塊在同一個項目中，此時若是4我的都是在主分支trunk上進行開發 那麼必須等兩個功能模塊所有ok 才能上線 （操做比較簡單 不進行贅述）

缺點：

• 開發耦合性過大
• 項目代碼不易管理

面向branches開發

分支開發 對trunk進行分支開發 按照上面的邏輯 新建兩個分支，2我的編輯一個分支 ，當其中一個分支開發完成 能夠直接發佈 另外兩人開發完成後再發布

優勢：

• 減小團隊做業之間的耦合性
• 代碼管理更加方便

svn使用流程

流程圖

步驟詳解

開發過程

1. 針對trunk進行 branches or tag的操做 建立新的分支 命名好比：

   20180822_test_demoproject 規則：時間_功能模塊__項目名稱

2. 將新建的分支 checkout 至本地

3. 開發新的功能 並作本地測試 （這個過程會有屢次commit）

4. 本地測試完成 將代碼提交到svn 對應的branches上面

5. 在beta服務器上面進行發佈branches的代碼並進行測試

準備發佈過程（同步trunk）

在開發過程當中 trunk可能已經被別的小組修改 因此此時須要同步trunk代碼

6. 使用本地branches做爲工做空間 merge from trunk 將trunk上面新增的代碼 merge到本地 （此時本地branches中的代碼是最完整的）
7. 將新增的代碼 提交至svn branches （此時能夠進行一次beta上面的迴歸測試）

review代碼 發佈

此時如何進行代碼的review是一個問題 好比在3的步驟中 進行了屢次提交 開發者已經不知道在開發新功能的時候提交了哪些代碼 此時若是貿然進行發佈 可能會出現一些意想不到的狀況 好比修改了配置文件 沒有修改回來 會致使線上出現很大的問題， 那麼如何進行代碼的review請看下面的步驟

8. 將svn trunk上的代碼checkout至本地 merge from svn branches 此時至關於將branches中的這個功能模塊全部的新增或者修改的代碼 merge到了本地的trunk上面
9. 此時進行commit 在提交以前 必定記得仔細review每個提交的代碼文件 是否正確 review完成肯定沒有問題再提交 這一步爲重中之重！！！ 不可省略，切記！

原文地址

有不足之處還望不吝賜教 歡迎關注

未經做者容許 請勿轉載，謝謝 :)