軟件源碼版本管理規(guī)范

范第一章目的本規(guī)范具體規(guī)定軟件項目版本管理的對象、存儲目錄、分支、權限、維護等內容，使軟件項目版本管理流程化并規(guī)范化，保證在系統開發(fā)和實行過程中項目的完整性和一致性。合用范圍所有系統開發(fā)及實行項目的軟件項目都應進行版本管理。項目中所有正式文檔和代碼都應納入配置庫(可使用工具建立配置庫，本文所述使用的是SVN)進行版本管理。職責配置庫管理員：負責配置庫的平常維護和管理；監(jiān)督開發(fā)及測試部門及時提交版本管理對象(即配置項)。第四章內容4.1.版本管理對象劃4.2.配置庫的目錄結構.分支(branch)的使用，可按照以下方式進行分支的管理。三個分支，涉及主版本開發(fā)(trunk)、分支版本開發(fā)(branches)和發(fā)布(tags)。4.權限管理.4.1.開發(fā)工程師.4.2.測試工程師.4.3.配置庫管理員.4.4.其別人員4.5.版本管理。.5.1.版本維護改的配置項，應從配置庫中檢出(checkout)后修改，修改完畢后及時檢入(checkin)，并填寫修改的.2.分支遷移ug從測試分支到發(fā)布分支的遷移，由配置庫管理員操作。遷移的時機有：.5.3.版本升級每個系統新的版本不僅以分支形式存在于配置庫中，并且要以獨立壓縮包形式備份。.5.4.版本基線定義獲取各項目最新的源程序、配置文獻和文檔，形成發(fā)布分支、測試分支和開發(fā)分支。.6.第五章版本提交準則6.1.提交之前先更新并時會產生沖突。這種情況就需要同之前的開發(fā)人員聯系，兩人一起協，還需要兩人一起測試，以保證解決沖突之后，各自的程序不會受到在更新時注意所更新文獻的列表，假如提交過程中產生了更新，則需要重新編譯并且再次完畢單元測試，再進行提交。這樣既能了解別人修改了哪些文獻，同時也能避免合并錯誤導致代碼有錯。.6.2.保持原子提交僅提交自己修改的部分，最佳不要一下子將整個項目提交。要提交本地自動生成的文獻一般配置管理員都會將項目中一些自動生成的文獻或者與本地配置環(huán)境有關的文獻屏蔽提交(例如Eclipse不要提交不能通過編譯的代碼代碼在提交之前，一方面要確認自己可以在本地編譯通過，并且代碼在提交前已經通過自己的單元測試。假如在代碼中使用了第三方類庫，要把相應類庫文獻統一存儲在代碼相應目錄中并提交，以免項目組成員裝相應的第三方類庫，從而在更新代碼后引起代碼運營錯誤。不要提交自己不明白的代碼代碼在提交之后即被項目成員所分享。假如提交了不明白的代碼，自己看不懂，別人也看不懂，假如在以后出現了問題將會成為項目質量的隱患。因此在引入任何第三方代碼之前，保證對這個代碼有一個很清楚的了解(必要時應有相應文檔說明)。行開發(fā)(同一模塊)前溝通務分派，讓小組成員互相間了解對方的工作計劃與工作內容。這樣能盡也許的減少在開發(fā)過程中也許出現的沖突，提高開發(fā)效率。同時也可以在和成員的交流中發(fā)現自己之前設計的局限性，完善自己的設計。提交更新的信息采用明晰的標注假如提交空的標注或者不確切的標注將會讓項目組中其他的成員不了解本次簽入動作的背景情況(如新增/ +：表達增長了功能(新增功能)*：表達對某些功能進行了更改(修改功能)-：表達刪除了文獻，或者對某些功能進行了裁剪，刪除，屏蔽(刪除功能)?。簝?yōu)化功能代碼的執(zhí)行性能(代碼性能優(yōu)化)修改/