SVN版本管理：兩種開發模式

1 SVN標準目錄

Subversion有一個很標準的目錄結構，是這樣的。好比項目是proj，svn地址爲svn://proj/，那麼標準的svn佈局是：

這是一個標準的佈局，trunk爲主開發目錄，branches爲分支開發目錄，tags爲tag存檔目錄（不容許修改）。可是具體這幾個目錄應該如何使用，svn並無明確的規範，更多的仍是用戶本身的習慣。

trunk：主幹，若是說把一個軟件項目從開始到消亡比做一個故事的話，主線情節都在這裏被SVN記錄着。

branches：分支，有不少種用法，好比：版本發佈維護分支、新特性開發分支，甚至是缺陷修復分支等等。

tags：標籤，或者叫快照，某個版本發佈時候，都在這裏留檔。

示例如圖：

2 集中式：trunk進行主要開發

通常的，咱們的全部的開發都是基於trunk進行開發，當一個版本/release開發告一段落（開發、測試、文檔、製做安裝程序、打包等）結束後，代碼處於凍結狀態（人爲規定，能夠經過hook來進行管理）。此時應該基於當前凍結的代碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。

此時，若是發現了上一個已發行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（Developing Version）沒法知足時間要求，這時候就須要在上一個版本上進行修改了。應該基於發行版對應的tag，作相應的分支（branch）進行開發。

例如，剛剛發佈1.0，正在開發2.0，此時要在1.0的基礎上進行bug修正。按照時間的順序：

這是一種很標準的開發模式，不少的公司都是採用這種模式進行開發的。trunk永遠是開發的主要目錄。

3 分散式：分支進行主要開發

這種開發模式當中，trunk是不承擔具體開發任務的，主要承擔版本發佈，一個版本/階段的開發任務在開始的時候，根據已經release的版本作新的開發分支，而且基於這個分支進行開發。仍是舉上面的例子，這裏面的時序關係是。

這實際上是一種分散式的開發，當各個部分相對獨立一些（功能性的），能夠開多個dev的分支進行開發，這樣各人/組都不會相互影響。好比dev_2.0_search和dev_2.0_cache等。可是這樣merge起來就是一個很痛苦的事情。

因此，第六步進行 選擇性的merge，是能夠當2.0開發結束後一塊兒把dev_1.0（bugfix用）和dev_2.0（新版本開發用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，進行測試等以後再merge回trunk。

這兩種方法各有利弊，第一種方法是能夠獲得一個比較純的dev_2.0的開發分支，而第二種方法則更加的保險，由於要測試嘛。

多人協做時，第六步是最常常出問題的地方，嚴重的甚至會致使代碼被覆蓋回滾狀況，其緣由在於分支管理者建立分支後再也不或長時間從主幹拉回數據，致使最終合併回主幹時分支的文件甚至結構都與主幹有較大差異，產生較多衝突。須要人手解決，浪費了不少時間。

針對這個問題，是否有一種方案能夠在分支提交時即檢測該分支最後一次合併的版本是否與主幹版本相符，若是不符則不容許提交，強制要求你們養成從主幹拉數據的習慣呢？若是能夠實現，那麼在分支合併回主幹時將幾乎能夠消滅掉衝突。

當前解決思路主要有3種：

1. 不間斷強調使用SVN時要常常從主幹同步代碼到分支。該方案缺點很明顯，徹底依賴人工，不可信。

2. 在trunk裏單獨維護一個帶最新版本號的readme.md，每次更新trunk時更新該版本到更新的版本號。此後合併分支回主幹時判斷下分支時的readme.md是否和主幹裏的readme.md保持一致，若小於主幹，則強制同步主幹代碼到分支。該方案缺點是須要每次更新主幹代碼時都要強制手工維護版本號，容易出現低級錯誤——更新trunk時忘記更新readme.md裏的版本號等狀況。

3. SVN自己記錄版本更新信息，能夠經過在服務器端監控主幹，判斷提交前(pre-commit)檢測是否有分支最後一次合併版本號小於主幹版本號，若是小於則不容許提交，強制要求先從主幹合併。此方案是一種相對完美的方案。

以上呢，就是SVN的兩種開發模式了，具體哪一種好，並無定論。這裏大體的說一下各自的優缺點：

第一種開發模式（trunk進行主要開發，集中式）：

優勢：管理簡單。

缺點：當開發的模塊比較多，開發人數/小團隊比較多的時候，很容易產生衝突而影響對方的開發。由於全部的改動都有可能觸碰對方的改動。

第二種開發模式（分支進行主要開發，分散式）：

優勢：各自開發獨立，不容易相互影響。

缺點：管理複雜，merge的時候很麻煩，容易死人。

4 最後，推薦第一種開發模式

責職說明：

Trunk：用於各版本開發提交代碼

TAG：用於記錄和保存每一個release/milestone的代碼

Branch：用於bug fixing

過程說明：

1. 項目開始時，建立Trunk，開始1.0.0開發

2. 全部小組成員都往Trunk中提交代碼

3. 當1.0.0開發完成後，建立一個標籤：Tag1.0.0

4. Tag1.0.0測試完成後，部署到服務器

5. 開發小組開始新版本1.0.1開發，繼續提交代碼到Trunk中

6. 1.0.1開發完成，建立Tag1.0.1，測試完後部署到服務器

7. 開發小組開始新版本1.0.2開發，繼續提交代碼到Trunk中

8. 1.0.1運行中發現bug，須要緊急修復 -> 從Tag1.0.1中建立1.0.1bug-fix Branch

9. Bug修復代碼提交到1.0.1bug-fix Branch，測試經過後，部署到服務器

10. 提交到1.0.1bug-fix Branch的代碼合併到Trunk中

11. And so on……