SVN源代碼管理規(guī)范精

1、1i:CDYWsoftSVN源代碼管理規(guī)范i>n7 s I呂HL n)nvSVN簡述、E '-rlTX Subversion是一種集中的分享信息的系統(tǒng)，它 的核心是版本庫，儲靜所有的數(shù)據(jù)，版本庫按 照文件樹形式儲存數(shù)據(jù)一包括文件和目錄，任 意數(shù)量的客戶端可以連接到版本庫，讀寫這些 文件。通過寫數(shù)據(jù)，別人可以看到這些信息； 通過讀數(shù)據(jù)，可以看到別人的修改。M Subversion會記錄每一次的更改，不僅針對文 件也包括目錄本身，包括增加、刪除和重新組 織文件和目錄SVN版本庫結(jié)構X TrunkX BranchesX TagsTRUNKX任何時候Trunk里包含的都是最新開發(fā)代碼。這

2、里的 代碼將會工作到你的下一個主要發(fā)布版本。X據(jù)我所見，幾乎常常人們只使用trunk來存放他們的 代碼。發(fā)放了一個版本后繼續(xù)在其上進行下一版開 發(fā)。這不好，無論是對你還是你的產(chǎn)品。X Trunk應該只被用來開發(fā)將會成為你的下一個重要版 本的代碼。不要給trunk加上版本號和發(fā)布名稱。僅 需要保證trunk在任何時候都處于“開發(fā)模式” OBRANCHES Release Branches Bug fix branches Experimental branchesRELEASE BRANCHES當trunk達到準備發(fā)布的階段時（或者你想凍結(jié)新特色 的添加時），你應該創(chuàng)建一個release bra

3、nches。 Release branches只是彳爾當前trunk的一個副本o這類branches可 以被單獨簽出 你也可 以啟動branches 和基于此版本的項目。你還可以使用此分支在測試期 間修復Bug。這種方式能夠保證trunk繼續(xù)開發(fā)，而不 會被發(fā)布某個具體的版本所干擾。因此當你準備發(fā)布 一個祈版未0,這屛不會影徐trunk增加薪殆功能。 命名方式：RB-X.XXBUG FIX BRANCHES分支也可以用 于處理trunk或release brarches里發(fā)現(xiàn)的嚴重 的Bug。當某些Bug很復雜，你不能通過只提交一次就修復他 們。因此為了集中精力修正此錯誤，你應該為此問題創(chuàng)建一

4、 個新的分io這樣就木會影響trunk和release branches斫繼 續(xù)進行，并且你也不會因為發(fā)現(xiàn)渤的Bug和測試而干擾此 Bug的修復。Bug修復分支的命名通常遵循下列方式：使用你的缺陷管理 系統(tǒng)分配給此Bug的ID。通常這是一個數(shù)字Q如：Bug-3391o當然，你也可以象其它分支一樣訪問你的Bug分支。EXPERIMENTAL BRANCHES有時你想將某個新技術引進項目。這很好，但是你當然不想 賭上你的整個項目。想象一下，你想把你的Web程序從PHP4 改為PHP5o你?；ǘ嗌贂r間？在這期間你的trunk停止使用？ ft到你把所有到PHP5的轉(zhuǎn)換做完！這是實驗，可能PHP5就像彩

5、虹的另一端一樣離你的程序太遠 了，你應該給他創(chuàng)建一個分支。你可以在分支里進行更改， 如采失敗了，你在當前分支仍然有PHP4的代碼。如采失敗了，實驗分支可以拋棄。如采成功，你可以很容易 的蔣套合并到trunk并繼續(xù)你的新技術0賣恣分支裕名遵循汪 面原則：為其名字加上前綴“TRY/ OXTAGSX標簽就像分支一樣備份你的代碼。但是 Tag不被用來開發(fā)，他們只是用來標記你 代碼的狀態(tài)OTAGSX標簽就像分支一樣備份你的代碼。但是 Tag不被用來開發(fā)，他們只是用來標記你 代碼的狀態(tài)。 Release tags Bug fix PRE and POST tagsRELEASE TAGSM Release

6、 Tags標記你版本發(fā)布點的代碼。 Release Tag永遠是相應發(fā)布分支的副本。 Release Tagx命名規(guī)則：“RELZ 前綴加上版本號。BUG FIX PRE AND POST TAGSX當你創(chuàng)建了一個Bug fix分支，你想標記代 碼在BugFix之前和之后的狀態(tài)。這樣你就 浪容易的引用你所做的更改，合并到trunk 或Release branches。X命名規(guī)則：+ “P RE/ 加上 BugID;+ “POST” 加上Bug ID。SVN使用規(guī)范先更新，再提交多提交不要提交不能通過編譯的代碼 每次提交必須書寫明晰的標注提交時注意不要提交本地自動生成的臨 時文件不要提交自己不明

7、白的代碼 慎用鎖定功能先更碼珥提交SVN更新的原則是要隨時更新，隨時提交。當完成了一個 小功能，能夠通過編譯并且自己測試之后，謹慎地提交。如果在修改的期間別人也更改了svn的對應文件，那么 commit就可能會萸敗。如果別人和自 己更改的是向一個文 件，那么update時會自動進行合并，如果修改的是同一行, 那么合并時會產(chǎn)生沖究，這種情況就需要同之前的開發(fā)人 員聯(lián)系，兩個人一起協(xié)商解決沖突，解決沖突之后，需要 兩人一起測試保證解決沖突之后，程序不會彬響其他功能。在更新時注意所更新文件的列表，如果提交過程中產(chǎn)生了 更新，則也是需要重新編譯并且完成自己的一些必要測試, 再進行提交。這樣既能了解別人

8、修改了哪些文件，同時也 能避免SVN合并錯誤導致代碼有錯。X多提交X每次提交的間歇盡可能地短，以幾個小 時的開發(fā)工作為宜。例如在更改UI界面 的時候，可以每完成一個UI界面的修改 或者設計，就提交一次。在開發(fā)功能模 塊的時候，可以每完成一個小細節(jié)功能 的測試，就提交一次，在修改bug的時 候，每修改掉一個bug并且確認修改了 這個bug,也就提交一次。我們提倡多 提交，也就能多為代碼添加上保險。X代碼在提交之前，首先要確認自己能夠 在本地編譯。如果在代碼中使用了第三 方類庫，要考慮到項目組成員中有些成 員可能沒有安裝相應的第三方類庫。項 目經(jīng)理在準備項目工作區(qū)域的時候，需 要考慮到這樣的情況，

9、確保開發(fā)小組成 員在簽出代碼之后能夠在統(tǒng)一的環(huán)境中 進行編譯。每次提交必須書寫 明 晰的標注m 小 口eg，：w3c在一個項目組中使用SVN,如果提交空 的標注或者不確切島標注將會讓項目組 中其他的成員感到很無奈，項目經(jīng)理無 痰很清晰的掌握工作進度，無法清晰的 把握此次提交的概要信息。在發(fā)現(xiàn)錯誤 后也無法準確的定位引起錯誤的文件。 所以，在提交工作時，要填寫明晰的標 注，能夠概要的描述所提交文件的信息, 讓項目組其他成員在看到標注后不用詳 細看代碼就能了解你所做的修改。不耍提交本地自動生成的文件M 例如eclipse 中 的.classpath 文件, Windows生成的縮略圖Thumbs.db,項目 編譯生成的臨時文件obj等等。如果項 目中沒有進行這方面的配置來強行禁止 提交這樣的文件，請自覺不要提交這樣 的文件。提交了這樣的文件后，別人在 更新后就可能與本地的環(huán)境沖突從而影 響大家的工作。不耍提交自己不明白的代碼其代碼在提交入SVN之后，你的代碼將被 項目成員所分享。如果提交了你不明白 的代碼，你看不懂，別人也看不懂，如 果在以后出現(xiàn)了問題將會成為項目質(zhì)量 的隱患。因此在引入任何第三方代碼之 前，確保你對這個代碼有一個很清晰