1、實用標準文案軟件版本管理規范1 .第一章目的本規范詳細規定軟件項目版本管理的對象、存儲目錄、分支、權限、維護等內容，使軟件項目版本管理流程化并規范化， 確保在系統開發和實施過 程中項目的完整性和一致性。2 .第二章適用范圍所有系統開發及實施項目的軟件項目都應進行版本管理。 項目中所有正式 文檔和代碼都應納入配置庫（可使用工具建立配置庫，本文所述使用的是 SVN進行版本管理。3 .第三章職責配置庫管理員：負責配置庫的日常維護和管理；監督開發及測試部門及時 提交版本管理對象（即配置項）。此崗位可由開發或測試人員兼任。4 .第四章內容4.1. 版本管理對象包括但不限于：項目總體計劃1可行性研究報告開

2、發計劃需求說明書1需求設計原型1設計說明書1系統開發變更申請單1系統管理手冊用戶操作手冊培訓計劃“培訓記錄源程序1支持系統運行的配置文件存儲過程腳本1測試計劃1測試用例1測試腳本1測試報告1上線計劃上線申請版本維護日志4.2. 配置庫的目錄結構每個項目在配置庫中應擁有唯一的項目名稱。配置庫目錄結構與項目內部的目錄結構建議按下列格式創建。配置庫目錄結構規劃：Hags（發布）| 卜 v1.0.0_T1_2016909| 卜 v1.0O33899_T1_20161009| 卜 v1.0.0_R1_20161109| 卜 v1.1.0_T1_20170109I Lv1.1.0_R1_20170209H

3、runk（主版本）I JprojectAI 卜 srcI Hmy_moocI 卜 docI Hool| Ho o oLbranches（分支）卜 SY_ABC卜 TJ_ABC卜 WH_MOOC其中，項目內部的目錄結構:一projectA-src （保存該項目的源程序）-doc （保存項目相關文檔）-000.項目管理（保存項目過程管理相關文檔）-010.項目計劃（保存項目計劃相關文檔）-020.項目需求（保存項目需求相關文檔）-030.系統設計（保存項目設計相關文檔）-030.系統測試（保存項目代碼測試相關文檔）-040.系統實施（保存項目部署實施相關文檔）-050.系統運維（保存項目運維文檔，

4、包括培訓、用戶手冊等）-060.技術資料（保存項目技術文檔，包括第三方技術資料等）（保存項目過程管理相關文檔）-tool（包括該項目特定的開發、編譯、測試等工具）4.3. 分支（branch）建議使用分支來協同不同職能小組對同一個配置庫的使用，可按照以下方式進行分支的管理。解決方案建立三個分支，包括主版本開發（trunk）、分支版本開發（branches）和 發布（tags）。1主版本開發是所有分支版本的基準版本，主版本的開發分支。開發部門開發使用。分版本開發主版本的分支版本，供開發部門開發使用。開發工程師如果以主版本為基準，進行軟件項目開發，要先將trunk目錄下的代碼分支到branches

5、目錄的一個子目 錄，在那里對代碼進行開發。多個主版本的分版本可通過在branches頂級目錄創建多個分支目錄來區分。、發布測試和發布專用分支，該分支代碼不允許任何形式的修改。每個經過測試后的不同版本的代碼做快照放到此分支文件夾下。4.4. 權限管理應對配置庫的訪問權限進行管理，確保軟件系統的完整性和安全性。建議按如下 方式進行管理。4.4.1. 開發工程師僅擁有自己所屬項目的 add file 、delete file 、check out、check in 權限， 無目錄創建和刪除權限。開發工程師若想創建目錄，需向配置庫管理員申請。4.4.2. 測試工程師擁有每個項目的測試分支的 add f

6、ile 、delete file 、check out、check in 權 限，無目錄創建和刪除權限，對于其他分支只有只讀權限。4.4.3. 配置庫管理員擁有全部權限，但增刪項目和增刪目錄需要有項目負責人批準。4.4.4. 其他人員若需要配置庫訪問權限，需經技術總監或經技術總監授權的項目經理批準，由配置庫管理員分配權限。4.5. 版本管理應對軟件系統的版本進行管理，確保版本的準確性和可追溯性。建議按如下方式 進行管理。4.5.1. 版本維護軟件工程各階段產生的各種文檔和代碼，應及時并統一上載到配置庫由配置庫管 理員統一管理。對于要修改的配置項，應從配置庫中檢出(check out)后修改，

7、修改完畢后及時檢入(check in),并填寫修改的原因和內容。配置項的歷史版 本應保存在配置庫中。4.5.2. 分支遷移從開發分支到測試分支的遷移，由開發工程師操作。遷移的時機有：1 .當開發負責人提交測試申請時；2 .開發過程中進行測試，修改好一個或多個 bug,需要測試工程師驗證時。從測試分支到發布分支的遷移，由配置庫管理員操作。遷移的時機有：1 .當開發組提交上線申請時。對于每個項目從測試分支到發布分支的遷移，配置庫管理員要建立分支遷移日志， 并詳細記錄。4.5.3. 版本升級軟件系統遷移到發布分支后，生成新的版本。每個系統新的版本不僅以分支形式存在于配置庫中，并且要以獨立壓縮包形式備

8、 份。版本的命名規則為，version N1.N2.N3.N4_T/R5_YYYYMMDD1. N1是系統編號。當項目整體重新設計時，N1加1,基數為12. N2是模塊編號。當模塊重新設計時，N2加1,基數為03. N3是功能編號。當項目增加某一功能，或某一功能需要修改時，N3加1,基數為04. N4是BU編號。當項目的BUG®修復時，N4加1,基數為05. T/R5中的T/R分別對應Test/Release 。當項目發布時為R,當項目提交測試 時為T, T/R5數值基數為0,以發布/測試提交順序遞增加1。6. YYYYMMDD表生成版本的實際年月日，如：201602024.5.4.

9、 版本基線定義公司首次采用版本管理規范時，可以采取下列方法定義一個基線版本。獲取各項目最新的源程序、配置文件和文檔，形成發布分支、測試分支和開發分 支。對每個項目的提測和發布分支都生成一個版本基線，如：Version1.0.0_R1_20160202 。4.6. 第五章版本提交準則4.6.1. 提交之前先更新更新的原則是要隨時更新，隨時提交。當完成了一個小功能，能夠通過編譯并且 自己測試之后，謹慎地提交。如果在修改的期間其他同事也更改了同一個文件，那么update更新時會自動進行合并，如果修改的是同一行或者二者修改差異過大，那么合并時會產生沖突。這種情況就需要同之前的開發人員聯系，兩人一起協商

10、解決合并沖突。解決合并 沖突之后，還需要兩人一起測試，以保證解決沖突之后，各自的程序不會受到影 響。在更新時注意所更新文件的列表，如果提交過程中產生了更新，則需要重新編譯 并且再次完成單元測試，再進行提交。這樣既能了解別人修改了哪些文件， 同時 也能避免合并錯誤導致代碼有錯。4.6.2. 保持原子提交為確保在需要時可以隨時回溯代碼版本，每次提交的代碼只能包含實現一個獨立、 完整功能所必需的代碼，不能夾帶提交其他與此功能不相關的代碼。為盡早提交， 也可以將此獨立、完整功能分解為若干小細節功能，分別開發并提交所必需的代 碼，但必須確保多次提交的功能代碼組合在一起，完全實現此獨立、完整功能。僅提交自

11、己修改的部分，最好不要一下子將整個項目提交。每完成一個獨立、完整的功能后，最好盡早提交，以免后續更改時出現bug,無法恢復到正常代碼。每次提交的間歇盡可能地短，以幾個小時的開發工作為宜。我們提倡多提交，也 就能多為代碼添加上保險。為做到盡早提交，在開發功能模塊的時候，先將功能 分解成一個個獨立的、不可再分割的小細節功能，分別完成。每完成一個并通過 單元測試，就提交一次。在修改bug的時候，每修改掉一個bug并且確認修改了 這個bug,也就提交一次。4.6.3. 不要提交本地自動生成的文件一般配置管理員都會將項目中一些自動生成的文件或者與本地配置環境有關的 文件屏蔽提交（例如 Eclipse中的

12、.classpath 文件等，Visual Studio中的.suo 文件，Debug,Release,Obj等編譯文件夾及其下文件，以及其他的一些自動生成， 同編譯代碼無關的文件）。如果項目中沒有進行這方面的配置來強行禁止提交這 樣的文件，請自覺不要提交這樣的文件，如果不小心簽入了，需要從配置庫中刪 除，以免其他同事在更新后就可能與本地的環境沖突從而影響大家的工作。4.6.4. 不要提交不能通過編譯的代碼代碼在提交之前，首先要確認自己能夠在本地編譯通過， 并且代碼在提交前已經 通過自己的單元測試。如果在代碼中使用了第三方類庫，要把相應類庫文件統一存儲在代碼相應目錄中 并提交，以免項目組成員中

13、有些成員可能沒有安裝相應的第三方類庫，從而在更新代碼后引起代碼運行錯誤。4.6.5. 不要提交自己不明白的代碼代碼在提交之后即被項目成員所分享。如果提交了不明白的代碼，自己看不懂，別人也看不懂，如果在以后出現了問題將會成為項目質量的隱患。 因此在引入任 何第三方代碼之前，確保對這個代碼有一個很清晰的了解（必要時應有對應文檔 說明）。4.6.6. 并行開發（同一模塊）前溝通如果開發小組采用并行開發模式開發同一模塊功能，在開發前，需要對協作開發進行合理的工作計劃與任務分配，讓小組成員相互間了解對方的工作計劃與工作 內容。這樣能盡可能的減少在開發過程中可能出現的沖突，提高開發效率。同時也能夠在和成員

14、的交流中發現自己之前設計的不足，完善自己的設計。4.6.7. 對提交更新的信息采用明晰的標注如果提交空的標注或者不確切的標注將會讓項目組中其他的成員不了解此次簽 入動作的背景t#況（如新增/修改簽入的原因是什么？新增/修改什么內容？）， 項目經理無法通過提交的標注信息， 清晰的掌握開發工作進度細節進度。 沒有清 晰標注，甚至會對回溯代碼版本造成影響。所以，在提交工作時，要填寫明晰的 標注，能夠概要的描述所提交文件的信息， 讓項目組其他成員在看到標注后不用 詳細看代碼就能了解你所做的修改。統一的標注格式為：簽入動作+" " +" #" +標識ID+" ；” +簽入內容+“；”+簽入原因 簽入動作：十 :表示增加了功能（新增功能）一表示對某些功能進行了更改（修改功能）-:表示刪除了文件，或者對某些功能進行了裁剪，刪除，屏蔽（刪除功能）八:表示修正bug （修復功能缺陷）!:優化功能代碼的執行性能（代碼性能優化）標識ID