版本管理是軟體研發管理中比較容易忽視的一環，這當然是比較好理解的，因為版本管理畢竟和具體業務關係不大。其實，版本管理是很多更高階管理制度的基礎，如果版本管理做得糟糕，類似程式碼審查一類的工作就很難高效方便的執行。

         下面介紹目前我們研發團隊建議實行的版本管理制度，僅供參考。

1 工具軟體：SVN 和 Beyondcompare

         SVN是程式碼備份軟體，Beyond compare 是程式碼對比軟體

2 版本日誌

         我們要求，每個專案都應當有自己獨立的版本日誌檔案，小的專案或者模組版本日誌可以 TXT格式，大的可以用 excel 來儲存。

         版本日誌顧名思義，就是記錄專案版本演進的歷史。它應當包含的內容有：序號、版本號、提交時間、作者、新增功能、修復bug列表和依賴模組資訊。

         版本日誌存放的目錄一般是專案根目錄的 ./doc 子目錄，直接存放到專案根目錄也很好。

         序號：每提交一次，序號加一。

         版本號：要求每次提交都採用唯一的版本號標示。版本號一般由數字加字母組成，如 V 1.05a 這個版本號，“1.05 ”描述的是軟體功能集合，也就是說，V 1.05b、V 1.05c 的功能和 V 1.05a 完全一致，a、b、c 代表軟體修復的bug 在減少。

         提交時間：版本提交SVN的日期。

         作者：提交人。

         新增功能：軟體新增加的功能列表，只要軟體功能增加，則版本號的數字也應當增加，若某版本沒有新增功能，則版本號數字不應當變更。新增功能的描述詳盡程度以產品經理或者測試功能師能理解為準，太詳細了也沒必要，過於簡單或者有歧義也不行。

         修復bug列表：如果修復的bug 是測試部門報告的bug，則用 bug編號記錄。如果是研發自己發現的 bug，則應當簡要描述bug 現象，方便測試工程師驗證。

         依賴模組資訊：稍微大一點的專案，必然會依賴於大量的獨立模組，這些模組可能是第三方開源模組，也可能是公司其他部門或者團隊提供的模組，當然，也可以是自己研發的通用功能模組。這些模組名字、版本號必須在版本日誌中描述，尤其是這些模組的變更資訊，應當明確的進行描述。

         版本日誌的注意事項：我們明確的規定，如果既沒有新增功能，也沒有修復bug，則不允許進行程式碼提交。在很多團隊的研發實踐中，常常把 SVN 當做日常研發的程式碼備份工具，程式碼稍微寫了一點，就馬上進行提交，比如在開發某一個功能時需要3天時間，有些工程師會有每天下班提交成果到 SVN 的習慣，這種習慣不能說不好，但是我個人感覺不是最好，我相信過多的冗餘資訊會把真正有用的資訊掩蓋，所以，我建議的原則是隻把真正有用的資訊儲存下來，同時要求，所有有用的資訊都必須儲存下來！對一個軟體的開發工作而言，新增功能和修復bug 是我們編寫程式碼的全部目的，因此，我們就只關注這兩點，而過程則不在專案SVN中記錄。

3 提交內容

         提交內容應當包括：版本日誌、相關程式碼和資原始檔等。

         提交的內容應當是完整的、可編譯的。這句話的意思是，其他同事在一個新的機器（開發編譯環境自己可以安裝）上把程式碼從SVN上Check Out 下來後，可以順利完成專案的編譯。某些專案編譯環境有一些特殊的需求，比如要打一些特殊的定製補丁等，對這樣的專案，開發人員有義務在 SVN 的 ./doc 目錄下進行詳盡說明，並完整上傳定製補丁在 ./patch 目錄下。

         在公司有配置管理員的情況下，建議專案編譯生成的 bin 檔案（即專案成果，如 exe、DLL 或者 *.so 等）由配置管理員編譯生成並提交。在沒有配置管理員的情況，對重大專案，我們建議採取交叉編譯提交的方式，即開發人員只負責提交自己的程式碼，然後相互編譯其他同事的程式碼和上傳別人的 bin檔案。這種管理方式有時候可以提前避免很多非技術性糾紛。

         開發人員在提交程式碼前，必須對完成的功能和修復的bug 自己做一次冒煙測試，即冒煙測試原則上應當研發人員自己完成。

         對於程式碼編譯過程中產生的一些中間檔案，典型的如 *.obj、*.o、*.s 等檔案，嚴禁提交到 SVN。很多工程師提交這些檔案的原因主要是對 SVN 不熟。

         另外，需要著重指出的是，提交的程式碼，應當是和版本日誌中描述的新增功能和修復bug 相關的。在實踐中，有工程師在程式設計時會發現以前某些程式碼檔案的版式不漂亮、程式碼註釋太多等等，然後就隨手做了一些修改；另外就是在提交程式碼時，某些正在進行中的功能開發程式碼也順便做了提交。就我個人的建議，這不是好的做法，我們應當盡力避免。因為版本日誌是版本管理的總綱，版本日誌的核心又是新增功能和修復bug兩項，這意味著我們提交的程式碼是圍繞著這兩個核心進行的。在SVN的提交日誌上可以清楚看到每次提交的程式碼檔名，如果按照規定做的話，這些檔名應當是完整說明了版本日誌中對應的功能和修復bug所需要新增或者修改的程式碼檔案，在這裡，我不希望出現冗餘資訊，理由前面說過。

4 提交時間

         我們建議採取以功能點和修復的bug為線索的提交方式，即完成一個功能或者修復一個bug 後就立即提交。

         先把提交版本和釋出版本的概念做一個清晰定義。提交版本意即開發工程師完成若干功能或者修復若干bug 後，把程式碼上傳到SVN伺服器，而釋出版本意即由配置管理員從SVN更新到最新程式碼，並進行編譯和bin提交，然後把bin釋出給測試部門。

         我們建議採取的是多次提交對應一次釋出的原則，而很多研發團隊事實上採取的是一次提交對應一次釋出的原則，即在版本釋出的截止時間點做一次匆忙的提交活動，這種方式是可能存在一些隱患的。

5 優勢

         採用這樣的版本管理方法，研發團隊是可以獲取很多好處，也可以在流程上預先排除一些隱患。當然，自賣自誇不是好習慣，所以這部分我只是簡單的說幾點，真正的益處，是要大家在實踐中去體會的，當然，可能也還有缺點也不完善，這也需要大家在實踐中去發現。

         有些工程師出於各種原因，可能沒有完整提交程式碼，對這種現象，我們採取了增加配置管理員編制的方法來解決。

         有些團隊一方面提交的程式碼和最終生成的bin 不一致，另一方面，SVN伺服器上的bin 和測試的bin 又可能不一致，對這種現象，配置管理員的設定解決了前者，而通過開放SVN上 ./bin 和 ./doc 兩個目錄許可權給測試部門可以解決後者。

         測試工程師對於釋出的版本可以採取增量測試的方法進行測試，減少測試工程師系統測試的次數，這樣可以極大的提高測試工程師的工作效率。所謂增量測試，指的是隻測試和驗證釋出版本的新增功能和修復的bug。

         剛釋出的版本很快就被測試打回，這個現象的原因很複雜，但是，通過研發人員自己完成冒煙測試可以極大緩解該現象。

         有利於培養研發工程師對待程式碼的嚴肅性，為程式碼規範等一系列規定創造一個比較好的環境。

         現在迴歸測試更方便和有效了。研發工程師通過迴歸測試的方式可以更容易的排查bug了。

         有些團隊測試平時很空閒，一發布版本就很忙，甚至有可能要搞通宵。現在我們通過多次提交對應一次釋出的方法來解決這個問題。測試平時就可以隨著研發的進行先把提交的版本測試起來，極大的提高的測試的工作效率，使得測試工程師的工作量安排分佈更加均勻。

         最大的好處是，使得團隊內部互相 code review 成為可能。Code review 是在研發階段消滅軟體質量最好的方法，也是促進新手程式設計師成長的最高效方式。在嚴格的版本管理制度下，每個功能、每個bug 對應修改的程式碼在SVN上可以簡明的看到，這極大的方便了資深工程師對新手程式碼的審查，同時，也極大的方便了新手程式設計師向資深工程師的學習。我一向的觀點是，軟體工程師把一個功能完成算不得什麼，如果百分制的話，完成功能最多得30分，我們除了功能，還應當考慮穩定性、可靠性、可擴充套件性，還有注重程式碼的可讀性和可維護性等等，這些東西新手程式設計師是很難全面兼顧的，這就需要資深工程師進行現場指導，結合新手工程師自己寫的程式碼進行講解，這是最快速的優秀程式設計師培養模式。