軟體版本控制規範

標籤：臨時檔案   clip   規則   並且   版本號碼   引入   產品開發   發展   詳細   

版本控制規範

1.     簡介1.1     目的

版本控制規範用於確定軟體配置項的命名與版本號碼管理的規則，以確保清楚地、唯一地標識軟體的各個組成部分及其狀態，並建立這些部分之間的一致性關係。

1.2     範圍

版本控制的範圍包括：

²  原始碼：用電腦程式設計語言編寫的原始碼檔案

²  文檔：需求文檔、架構設計文檔、資料庫設計文檔等描述軟體功能和結構的技術文檔；專案計劃等專案管理文檔以及各種測試文檔和使用者文檔

²  產品包：將原始碼進行編譯得到的可啟動並執行軟體系統

2.     產品標識

在每個軟體產品立項時建立該軟體產品的標識，以唯一地代表一個軟體產品或項目，產品標識也稱為項目標識。

 

2.1  產品名稱

新產品立項時，為產品賦予產品名稱；當已有產品升級時，則沿用前一版本產品的名稱。

產品名稱包括：

²  產品中文名稱：如：製造執行系統，倉庫管理系統等等

²  產品英文名稱：如：Manufacturing Execution Systems，Warehouse Management System

²  產品英文簡稱：如：MES，WMS

產品名稱用於相關文檔的編寫和產品的發布。

產品名稱不是某一產品的唯一標識，必須與版本號碼一起用才能標識特定產品。

2.2  版本號碼

版本號碼用來標識開發、測試、交付階段的不同狀態的產品，版本號碼格式為：

<主要版本號>.<次版本號碼>.<小版本號碼>-[Build號]

²  主要版本號：立項時設定，在整個項目開發過程中不改變

²  次版本號碼：立項時設定，在整個項目開發過程中不改變

²  小版本號碼：立項時設定，在整個項目開發過程中不改變

²  Release號：又叫Build號，自我裝載開始之前設定，初始值為0，此後每產生一次小的修改，Release號+1

版本號碼的一般形式如：1.0.7-101，2.0.0-900

3.     版本規範3.1  版本號碼設定規則3.1.1     主要版本號

1、  設定時間：產品立項時設定

2、  設定規則：

²  新產品立項，主要版本號為1

²  產品構架發生改變，主要版本號+1

²  產品主要組件（比如訂單處理架構）進行重大修改，主要版本號+1

²  產品對外介面協議發生更改，主要版本號+1

3.1.2     次版本號碼

1、  設定時間：產品立項時設定

2、  設定規則：

²  新產品立項，次版本號碼為0

²  為處理產品Bug或改進現有功能/效能，對現有功能模組做大的修改，但不增加新的功能模組，副版本號碼+1

²  為增加產品功能，在原版本產品上增加新的功能模組，而產品的主體構件未做重大修改，並且產品的主體構件之間的介面協議也未做修改，副版本號碼+1

²  為適應不同使用者需求，對產品變更，而產品的主體構件未做重大修改，並且產品的主體構件之間的介面協議也未做修改，副版本號碼+1

²  當主要版本號變更時，副版本號碼同時置0

3.1.3     小版本號碼

²  新產品立項，小版本號碼為0

²  修複Bug或改進現有功能，但不對現有功能模組做大的修改，不增加新的功能模組，小版本號碼+1

²  當次版本號碼變更時，小版本號碼同時置0

3.1.4     Build號

1、  設定時間：產品開發結束，自我裝載開始之前

2、  設定規則：

²  Release號初始值為0

²  測試過程中，每進行一次修改，Release號+1

3.2  版本管理3.2.1     trunk

任何時候trunk裡包含的都是最新的開發代碼。 這裡的代碼將會工作到下一個主要發布版本。

trunk應該只被用來開發將會成為你的下一個重要版本的代碼。 不要給trunk加上版本號碼和發布名稱。 僅需要保證trunk在任何時候都處於“開發模式”。

3.2.2     branches

有幾種不同類型的分支。在branches的目錄裡，可以為更多具體的目標建立路徑，像即將發行版本。Brahches可以包含了trunk在不同發展階段的副本。

3.2.2.1    Release Branches

當trunk達到準備發布的階段時（或者你想凍結新特色的添加時），應該建立一個release branches。 Release branches只是當前trunk的一個副本。

這個branches可以被單獨的簽出，也可以啟動branches和基於此版本的項目。還可以使用此分支在測試期間修複Bug。 這種方式能夠保證trunk繼續開發，而不會被發布某個具體的版本所幹擾。 因此當準備發布一個新版本時，不會影響trunk增加新的功能。

3.2.2.2  Bug fix branches

分支也可以用於處理trunk或release branches裡發現的嚴重的Bug。這些Bug很複雜，不能在一次提交時就修複他們。因此為了集中精力修正此錯誤，應該為此問題建立一個新的分支。這樣就不會影響trunk 和 release branches的繼續進行，並且也不會因為發現新的Bug 和測試而幹擾此Bug 的修複。

3.2.2.3  Experimental branches

有時想將某個新技術引進項目。但是不想影響到整個項目。比如想把web應用從spring3x改為spring4x。要花多少時間？在這期間trunk停止使用？直到把所有到spring的轉換做完。

可能Spring4x對程式變動較大，應該建立一個實驗分支。 這樣就可以在分支裡變更，如果失敗了，不影響當前應用，實驗分支可以拋棄。 如果成功，可以很容易的將其合并到trunk。

3.2.3     tags

tags用來備份代碼，通常是readonly的，不被用來開發，只是用來標記代碼的狀態。

3.2.3.1  1.3.1 Release tags

Release Tags 標記版本發布點的代碼。 Release Tag 永遠是相應發布分支的副本。 Release Tag命名規則：版本號碼+“Release”尾碼。

4.  SVN使用規範4.1  先更新，再提交

SVN更新的原則是要隨時更新，隨時提交。當完成了一個小功能，能夠通過編譯並且自己測試之後，謹慎地提交。

如果在修改的期間別人也更改了svn的對應檔案，那麼commit就可能會失敗。如果別人和自己更改的是同一個檔案，那麼update時會自動進行合并，如果修改的是同一行，那麼合并時會產生衝突，這種情況就需要同之前的開發人員聯絡，兩個人一起協商解決衝突，解決衝突之後，需要兩人一起測試保證解決衝突之後，程式不會影響其他功能。

在更新時注意所更新檔案的列表，如果提交過程中產生了更新，則也是需要重新編譯並且完成自己的一些必要測試，再進行提交。這樣既能瞭解別人修改了哪些檔案，同時也能避免SVN合并錯誤導致代碼有錯。

4.2  多提交

每次提交的間歇儘可能地短，以幾個小時的開發工作為宜。例如在更改UI介面的時候，可以每完成一個UI介面的修改或者設計，就提交一次。在開發功能模組的時候，可以每完成一個小細節功能的測試，就提交一次，在修改bug的時候，每修改掉一個bug並且確認修改了這個bug，也就提交一次。提倡多提交，也就能多為代碼添加上保險。

4.3  不要提交不能通過編譯的代碼

代碼在提交之前，首先要確保能夠在本地編譯。專案經理在準備項目工作區域的時候，需要確保開發小組成員在簽出代碼之後能夠在統一的環境中進行編譯。

4.4  每次提交必須書寫明晰的標註

在一個項目組中使用SVN，如果提交空的標註或者不確切的標註將會讓項目組中其他的成員感到很無奈，專案經理無法很清晰的掌握工作進度，無法清晰的把握此次提交的概要資訊。在發現錯誤後也無法準確的定位引起錯誤的檔案。所以，在提交工作時，要填寫明晰的標註，能夠概要的描述所提交檔案的資訊，讓項目組其他成員在看到標註後不用詳細看代碼就能瞭解你所做的修改。

4.5  提交時注意不要提交本地自動產生的檔案

例如eclipse中的.classpath檔案，Windows產生的縮圖Thumbs.db，項目編譯產生的臨時檔案.obj, .class等等。如果項目中沒有進行這方面的配置來強行禁止提交這樣的檔案，請自覺不要提交這樣的檔案。提交了這樣的檔案後，別人在更新後就可能與本地的環境衝突從而影響大家的工作。

4.6  不要提交自己不明白的代碼

 代碼在提交入SVN之後，你的代碼將被項目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以後出現了問題將會成為項目品質的隱患。因此在引入任何第三方代碼之前，確保你對這個代碼有一個很清晰的瞭解。

4.7  慎用鎖定功能

     在項目中要慎用鎖定的功能，在你鎖定了一個檔案之後別人就無法繼續修改提交該檔案，雖然可以減少衝突的發生率，但是可能會影響項目組中其他人員的工作。平時只有在編輯那些無法合并的檔案（例片檔案，flash檔案等）時，才適當的採用鎖定操作。

5.  目錄結構

 

 

 

軟體版本控制規範