版本控制規(guī)范

1、版本控制規(guī)范1. 簡(jiǎn)介1.1 目的版本控制規(guī)范用于確定軟件配置項(xiàng)的命名與版本號(hào)管理的規(guī)則，以確保清楚地、唯一地標(biāo)識(shí)軟件的各個(gè)組成部分及其狀態(tài)，并建立這些部分之間的一致性關(guān)系。1.2 范圍版本控制的范圍包括：² 源代碼：用計(jì)算機(jī)編程語(yǔ)言編寫的源代碼文件² 文檔：需求文檔、架構(gòu)設(shè)計(jì)文檔、數(shù)據(jù)庫(kù)設(shè)計(jì)文檔等描述軟件功能和結(jié)構(gòu)的技術(shù)文檔；項(xiàng)目計(jì)劃等項(xiàng)目管理文檔以及各種測(cè)試文檔和用戶文檔² 產(chǎn)品包：將源代碼進(jìn)行編譯得到的可運(yùn)行的軟件系統(tǒng)2. 產(chǎn)品標(biāo)識(shí)在每個(gè)軟件產(chǎn)品立項(xiàng)時(shí)建立該軟件產(chǎn)品的標(biāo)識(shí)，以唯一地代表一個(gè)軟件產(chǎn)品或項(xiàng)目，產(chǎn)品標(biāo)識(shí)也稱為項(xiàng)目標(biāo)識(shí)。2.1 產(chǎn)品名稱新產(chǎn)品立項(xiàng)時(shí)，

2、為產(chǎn)品賦予產(chǎn)品名稱；當(dāng)已有產(chǎn)品升級(jí)時(shí)，則沿用前一版本產(chǎn)品的名稱。產(chǎn)品名稱包括：² 產(chǎn)品中文名稱：如：訂單管理系統(tǒng)，倉(cāng)庫(kù)管理系統(tǒng)等等² 產(chǎn)品英文名稱：如：Order Management System，Warehouse Management System² 產(chǎn)品英文簡(jiǎn)稱：如：OMS，WMS產(chǎn)品名稱用于相關(guān)文檔的編寫和產(chǎn)品的發(fā)布。產(chǎn)品名稱不是某一產(chǎn)品的唯一標(biāo)識(shí)，必須與版本號(hào)一起用才能標(biāo)識(shí)特定產(chǎn)品。2.2 版本號(hào)版本號(hào)用來(lái)標(biāo)識(shí)開發(fā)、測(cè)試、交付階段的不同狀態(tài)的產(chǎn)品，版本號(hào)格式為：<主版本號(hào)>.<次版本號(hào)>.<小版本號(hào)>-Build號(hào)&

3、#178; 主版本號(hào)：立項(xiàng)時(shí)設(shè)置，在整個(gè)項(xiàng)目開發(fā)過(guò)程中不改變² 次版本號(hào)：立項(xiàng)時(shí)設(shè)置，在整個(gè)項(xiàng)目開發(fā)過(guò)程中不改變² 小版本號(hào)：立項(xiàng)時(shí)設(shè)置，在整個(gè)項(xiàng)目開發(fā)過(guò)程中不改變² Release號(hào)：又叫Build號(hào)，內(nèi)部測(cè)試開始之前設(shè)置，初始值為0，此后每產(chǎn)生一次小的修改，Release號(hào)+1版本號(hào)的一般形式如：1.0.7-101，2.0.0-9003. 版本規(guī)范3.1 版本號(hào)設(shè)置規(guī)則3.1.1 主版本號(hào)1、 設(shè)置時(shí)間：產(chǎn)品立項(xiàng)時(shí)設(shè)置2、 設(shè)置規(guī)則：² 新產(chǎn)品立項(xiàng)，主版本號(hào)為1² 產(chǎn)品構(gòu)架發(fā)生改變，主版本號(hào)+1² 產(chǎn)品主要組件（比如訂單處理框架）

4、進(jìn)行重大修改，主版本號(hào)+1² 產(chǎn)品對(duì)外接口協(xié)議發(fā)生更改，主版本號(hào)+13.1.2 次版本號(hào)1、 設(shè)置時(shí)間：產(chǎn)品立項(xiàng)時(shí)設(shè)置2、 設(shè)置規(guī)則：² 新產(chǎn)品立項(xiàng)，次版本號(hào)為0² 為處理產(chǎn)品Bug或改進(jìn)現(xiàn)有功能/性能，對(duì)現(xiàn)有功能模塊做大的修改，但不增加新的功能模塊，副版本號(hào)+1² 為增加產(chǎn)品功能，在原版本產(chǎn)品上增加新的功能模塊，而產(chǎn)品的主體構(gòu)件未做重大修改，并且產(chǎn)品的主體構(gòu)件之間的接口協(xié)議也未做修改，副版本號(hào)+1² 為適應(yīng)不同用戶需求，對(duì)產(chǎn)品進(jìn)行更改，而產(chǎn)品的主體構(gòu)件未做重大修改，并且產(chǎn)品的主體構(gòu)件之間的接口協(xié)議也未做修改，副版本號(hào)+1² 當(dāng)主版本

5、號(hào)變更時(shí)，副版本號(hào)同時(shí)置03.1.3 小版本號(hào)² 新產(chǎn)品立項(xiàng)，小版本號(hào)為0² 修復(fù)Bug或改進(jìn)現(xiàn)有功能，但不對(duì)現(xiàn)有功能模塊做大的修改，不增加新的功能模塊，小版本號(hào)+1² 當(dāng)次版本號(hào)變更時(shí)，小版本號(hào)同時(shí)置03.1.4 Build號(hào)1、 設(shè)置時(shí)間：產(chǎn)品開發(fā)結(jié)束，內(nèi)部測(cè)試開始之前2、 設(shè)置規(guī)則：² Release號(hào)初始值為0² 測(cè)試過(guò)程中，每進(jìn)行一次修改，Release號(hào)+13.2 版本管理3.2.1 trunk任何時(shí)候trunk里包含的都是最新的開發(fā)代碼。 這里的代碼將會(huì)工作到下一個(gè)主要發(fā)布版本。trunk應(yīng)該只被用來(lái)開發(fā)將會(huì)成為你的下一個(gè)重要版本

6、的代碼。 不要給trunk加上版本號(hào)和發(fā)布名稱。 僅需要保證trunk在任何時(shí)候都處于“開發(fā)模式”。3.2.2 branches有幾種不同類型的分支。在branches的目錄里，可以為更多具體的目標(biāo)創(chuàng)建路徑，像即將發(fā)行版本。Brahches可以包含了trunk在不同發(fā)展階段的副本。3.2.2.1 Release Branches當(dāng)trunk達(dá)到準(zhǔn)備發(fā)布的階段時(shí)（或者你想凍結(jié)新特色的添加時(shí)），應(yīng)該創(chuàng)建一個(gè)release branches。 Release branches只是當(dāng)前trunk的一個(gè)副本。這個(gè)branches可以被單獨(dú)的簽出，也可以啟動(dòng)branches和基于此版本的項(xiàng)目。還可以使用此

7、分支在測(cè)試期間修復(fù)Bug。 這種方式能夠保證trunk繼續(xù)開發(fā)，而不會(huì)被發(fā)布某個(gè)具體的版本所干擾。 因此當(dāng)準(zhǔn)備發(fā)布一個(gè)新版本時(shí)，不會(huì)影響trunk增加新的功能。3.2.2.2 Bug fix branches分支也可以用于處理trunk或release branches里發(fā)現(xiàn)的嚴(yán)重的Bug。這些Bug很復(fù)雜，不能在一次提交時(shí)就修復(fù)他們。因此為了集中精力修正此錯(cuò)誤，應(yīng)該為此問(wèn)題創(chuàng)建一個(gè)新的分支。這樣就不會(huì)影響trunk 和 release branches的繼續(xù)進(jìn)行，并且也不會(huì)因?yàn)榘l(fā)現(xiàn)新的Bug 和測(cè)試而干擾此Bug 的修復(fù)。3.2.2.3 Experimental branches有時(shí)想將某個(gè)

8、新技術(shù)引進(jìn)項(xiàng)目。但是不想影響到整個(gè)項(xiàng)目。比如想把web應(yīng)用從spring3x改為spring4x。要花多少時(shí)間？在這期間trunk停止使用？直到把所有到spring的轉(zhuǎn)換做完。可能Spring4x對(duì)程序變動(dòng)較大，應(yīng)該創(chuàng)建一個(gè)實(shí)驗(yàn)分支。 這樣就可以在分支里進(jìn)行更改，如果失敗了，不影響當(dāng)前應(yīng)用，實(shí)驗(yàn)分支可以拋棄。 如果成功，可以很容易的將其合并到trunk。3.2.3 tagstags用來(lái)備份代碼，通常是readonly的，不被用來(lái)開發(fā)，只是用來(lái)標(biāo)記代碼的狀態(tài)。3.2.3.1 1.3.1 Release tagsRelease Tags 標(biāo)記版本發(fā)布點(diǎn)的代碼。 Release Tag 永遠(yuǎn)是相應(yīng)發(fā)

9、布分支的副本。 Release Tag命名規(guī)則：版本號(hào)+“Release”后綴。4. SVN使用規(guī)范4.1 先更新，再提交 SVN更新的原則是要隨時(shí)更新，隨時(shí)提交。當(dāng)完成了一個(gè)小功能，能夠通過(guò)編譯并且自己測(cè)試之后，謹(jǐn)慎地提交。如果在修改的期間別人也更改了svn的對(duì)應(yīng)文件，那么commit就可能會(huì)失敗。如果別人和自己更改的是同一個(gè)文件，那么update時(shí)會(huì)自動(dòng)進(jìn)行合并，如果修改的是同一行，那么合并時(shí)會(huì)產(chǎn)生沖突，這種情況就需要同之前的開發(fā)人員聯(lián)系，兩個(gè)人一起協(xié)商解決沖突，解決沖突之后，需要兩人一起測(cè)試保證解決沖突之后，程序不會(huì)影響其他功能。在更新時(shí)注意所更新文件的列表，如果提交過(guò)程中產(chǎn)生了更新，則

10、也是需要重新編譯并且完成自己的一些必要測(cè)試，再進(jìn)行提交。這樣既能了解別人修改了哪些文件，同時(shí)也能避免SVN合并錯(cuò)誤導(dǎo)致代碼有錯(cuò)。4.2 多提交每次提交的間歇盡可能地短，以幾個(gè)小時(shí)的開發(fā)工作為宜。例如在更改UI界面的時(shí)候，可以每完成一個(gè)UI界面的修改或者設(shè)計(jì)，就提交一次。在開發(fā)功能模塊的時(shí)候，可以每完成一個(gè)小細(xì)節(jié)功能的測(cè)試，就提交一次，在修改bug的時(shí)候，每修改掉一個(gè)bug并且確認(rèn)修改了這個(gè)bug，也就提交一次。提倡多提交，也就能多為代碼添加上保險(xiǎn)。4.3 不要提交不能通過(guò)編譯的代碼 代碼在提交之前，首先要確保能夠在本地編譯。項(xiàng)目經(jīng)理在準(zhǔn)備項(xiàng)目工作區(qū)域的時(shí)候，需要確保開發(fā)小組成員在簽出代碼之后能

11、夠在統(tǒng)一的環(huán)境中進(jìn)行編譯。4.4 每次提交必須書寫明晰的標(biāo)注在一個(gè)項(xiàng)目組中使用SVN，如果提交空的標(biāo)注或者不確切的標(biāo)注將會(huì)讓項(xiàng)目組中其他的成員感到很無(wú)奈，項(xiàng)目經(jīng)理無(wú)法很清晰的掌握工作進(jìn)度，無(wú)法清晰的把握此次提交的概要信息。在發(fā)現(xiàn)錯(cuò)誤后也無(wú)法準(zhǔn)確的定位引起錯(cuò)誤的文件。所以，在提交工作時(shí)，要填寫明晰的標(biāo)注，能夠概要的描述所提交文件的信息，讓項(xiàng)目組其他成員在看到標(biāo)注后不用詳細(xì)看代碼就能了解你所做的修改。4.5 提交時(shí)注意不要提交本地自動(dòng)生成的文件例如eclipse中的.classpath文件，Windows生成的縮略圖Thumbs.db，項(xiàng)目編譯生成的臨時(shí)文件.obj, .class等等。如果項(xiàng)目中沒(méi)有進(jìn)行這方面的配置來(lái)強(qiáng)行禁止提交這樣的文件，請(qǐng)自覺(jué)不要提交這樣的文件。提交了這樣的文件后，別人在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。4.6 不要提交自己不明白的代碼 代碼在提交入SVN之后，你的代碼將被項(xiàng)目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以后出現(xiàn)了問(wèn)題將會(huì)成為項(xiàng)目質(zhì)