解決版本沖突

解決版本沖突一使用SVN主干與分支功能1前言大多數(shù)產(chǎn)品開發(fā)存在這樣一個(gè)生命周期：編碼、測試、發(fā)布，然后不斷重復(fù)。通常是這樣的開發(fā)步驟：1） 開發(fā)人員開發(fā)完畢某一版本（如版本A）功能后，提交測試；2） 測試人員對待發(fā)布版本A進(jìn)行測試，同時(shí)開發(fā)人員繼續(xù)開發(fā)新功能（如版本B）；3） 測試人員提交bug，研發(fā)人員修復(fù)bug，同時(shí)繼續(xù)開發(fā)新功能；4） 重復(fù)第3步驟，直到待發(fā)布版本A測試通過測試后，發(fā)布第一版本這樣就會(huì)存在以下問題：1） 如何從代碼庫中（A+B）分離出待發(fā)布版本A，進(jìn)行測試和發(fā)布；2） 如果單獨(dú)存放待發(fā)布版本A，那么開發(fā)組必須同時(shí)維護(hù)此版本庫A以及當(dāng)前最新代碼庫（A+B），操作冗余且容易出錯(cuò)。在SVN中，通常采用主干（trunk）與分支（branches）的方法，解決以上問題。2相關(guān)概念和原理在SVN中創(chuàng)建代碼庫時(shí)，通常會(huì)創(chuàng)建trunk、branches、tags三個(gè)子目錄，當(dāng)然，你也可以用其他名稱來實(shí)現(xiàn)主干和分支的功能trunk一主干，或稱主線，顧名思義，是開發(fā)的主線。branches一分支，是從主線上分出來，獨(dú)立于主線的另一條線?？梢詣?chuàng)建多個(gè)分支。一個(gè)分支總是從主干一個(gè)備份開始的，從那里開始，發(fā)展自己獨(dú)有的歷史（如下圖所示）。在版本控制的系統(tǒng)中，我們經(jīng)常需要對開發(fā)周期中的單獨(dú)生命線作單獨(dú)的修改，這條單獨(dú)的開發(fā)生命線就可以稱為Branches，即分支。分支經(jīng)常用于添加新的功能以及產(chǎn)品發(fā)布后的bug修復(fù)等，這樣可以不影響主要的產(chǎn)品開發(fā)線以及避免編譯錯(cuò)誤等。當(dāng)我們添加的新功能完成后可以將其合并到主干中。tags一標(biāo)記，主要用于項(xiàng)目開發(fā)中的里程碑，比如開發(fā)到一定階段可以單獨(dú)一個(gè)版本作為發(fā)布等，它往往代表一個(gè)可以固定的完整的版本。即主干和分支都是用來進(jìn)行開發(fā)，而標(biāo)記是用來進(jìn)行階段發(fā)布的。安全公司的配置庫有專門的發(fā)布區(qū)，所以tags并不需要?jiǎng)?chuàng)建，在這里只是提供說明，不推薦使用。branches以及tags在TortoiseSVN中創(chuàng)建方法是一致的，它們都是通過存儲(chǔ)類似Linux中的lunch快捷方式一樣，只是創(chuàng)建了指向某個(gè)版本的鏈接，而不會(huì)真正將此版本的內(nèi)容復(fù)制到分支或者標(biāo)記中，這樣既可以節(jié)省空間，也可以很快速的創(chuàng)建，被稱為''廉價(jià)的拷貝〃。為了便于創(chuàng)建分支和標(biāo)記，通常習(xí)慣于將Repository版本庫的結(jié)構(gòu)布置為:/branches,/tags,/trunk。分別代表分支，標(biāo)記以及主干。還有一點(diǎn)值得注意的是，SVN不推薦在創(chuàng)建的tag基礎(chǔ)上Revision，這種情況應(yīng)用branches,因?yàn)閠ag一般保持不變不作任何修改。3代碼的分支管理策略關(guān)于代碼管理的分支和發(fā)布策略，目前主要有兩種：一種是主干作為新功能開發(fā)主線，分支用作發(fā)布。另一種是分支用作新功能開發(fā)，主干作為穩(wěn)定版的發(fā)布。3.1分支用來發(fā)布典型操作步驟如下：1） 開發(fā)者提交所有的新特性到主干。每日的修改提交到/trunk：新特性，bug修正和其他。2） 這個(gè)主干被拷貝到''待發(fā)布〃分支。當(dāng)小組認(rèn)為軟件已經(jīng)做好發(fā)布的準(zhǔn)備（如，版本1.0）然后/trunk會(huì)被拷貝到/branches/1.0。3） 項(xiàng)目組繼續(xù)并行工作，一個(gè)小組開始對分支進(jìn)行嚴(yán)酷的測試，同時(shí)另一個(gè)小組在/trunk繼續(xù)新的工作（如，準(zhǔn)備2.0），如果一個(gè)bug在任何一個(gè)位置被發(fā)現(xiàn)，錯(cuò)誤修正需要來回運(yùn)送。然而這個(gè)過程有時(shí)候也會(huì)結(jié)束，例如分支已經(jīng)為發(fā)布前的最終測試'停滯〃了。4） 分支已經(jīng)作了標(biāo)記并且發(fā)布，當(dāng)測試結(jié)束，/branches/1.0作為引用快照已經(jīng)拷貝到/tags/1.0.0，這個(gè)標(biāo)記被打包發(fā)布給客戶。5） 分支多次維護(hù)。當(dāng)繼續(xù)在/trunk上為版本2.0工作，bug修正繼續(xù)從/trunk運(yùn)送到/branches/1.0，如果積累了足夠的bug修正，管理部門決定發(fā)布1.0.1版本：拷貝/branches/1.0至U/tags/1.0.1，標(biāo)記被打包發(fā)布。整個(gè)過程隨著軟件的成熟不斷重復(fù)：當(dāng)2.0完成，一個(gè)新的2.0分支被創(chuàng)建，測試、打標(biāo)記和最終發(fā)布，經(jīng)過許多年，版本庫結(jié)束了許多版本發(fā)布，進(jìn)入了維護(hù)〃模式，許多標(biāo)記代表了最終的發(fā)布版本。這種分支管理策略被廣泛的應(yīng)用于開源項(xiàng)目。比如freebsd的發(fā)布就是一個(gè)典型的例子。freebsd的主干永遠(yuǎn)是current，也就是包括所有最新特性的不穩(wěn)定版本。然后隨著新特性的逐步穩(wěn)定，達(dá)到一個(gè)發(fā)布的里程碑以后，從主干分出來一個(gè)stable分支。freebsd是每個(gè)大版本一個(gè)分支。也就是說4.x，5.x，6,x各一個(gè)分支。每個(gè)發(fā)布分支上只有bug修改和現(xiàn)有功能的完善，而不會(huì)再增加新特性。新特性會(huì)繼續(xù)在主干上開發(fā)。當(dāng)穩(wěn)定分支上發(fā)生的修改積累到一定程度以后，就會(huì)有一次發(fā)布。發(fā)布的時(shí)候會(huì)在穩(wěn)定分支上再分出來一個(gè)release分支。以6.x為例，就會(huì)有6.0,6.1,6.2...等發(fā)布分支。這種發(fā)布方法非常適用于產(chǎn)品線的發(fā)布管理。產(chǎn)品是要賣的，以前賣給客戶的版本仍需要繼續(xù)維護(hù)，而為了以后的市場，新功能也不斷地在增加。這種管理方法對已發(fā)布產(chǎn)品的維護(hù)工作和下一代產(chǎn)品的開發(fā)工作進(jìn)行了隔離。對于已經(jīng)發(fā)布的產(chǎn)品，只有維護(hù)的補(bǔ)丁發(fā)布。而新發(fā)行的產(chǎn)品不僅包括了所有的bug修改，還包括了新功能。這種方法具有如下缺點(diǎn)：首先，必須對主干上的新功能增加進(jìn)行控制。只能增加下一個(gè)發(fā)布里面計(jì)劃集成進(jìn)去的新特性。而且，已經(jīng)在主干上集成的新特性中的任何一個(gè)，如果達(dá)不到里程碑的要求，穩(wěn)定分支就不能創(chuàng)建，這很有可能影響下一個(gè)發(fā)布的計(jì)劃。開源項(xiàng)目可能這方面的壓力小一些，但是商業(yè)產(chǎn)品開發(fā)如果碰到這種情況就危險(xiǎn)了。還有一個(gè)缺點(diǎn)就是bug修改必須在各個(gè)分支之間合并。從分支和合并的一些實(shí)踐經(jīng)驗(yàn)上看，各個(gè)長期存在的分支之間必須要周期性的進(jìn)行合并，否則很容易引發(fā)合并沖突。可是各個(gè)stable分支以及release分支之間恰好是不能進(jìn)行合并而且還要長期存在的。因此，采用這種分支策略可能碰到的最大問題就是某個(gè)分支上的bug修改內(nèi)容往其它分支merge的時(shí)候出現(xiàn)的沖突。而且一旦發(fā)現(xiàn)一個(gè)bug，調(diào)查這個(gè)bug影響哪些分支的工作會(huì)隨著維護(hù)的發(fā)布分支的數(shù)量而增加。在非產(chǎn)品開發(fā)的外包軟件項(xiàng)目里面，這種發(fā)布方法的好處體現(xiàn)不出來，而缺點(diǎn)仍然存在。外包項(xiàng)目的特點(diǎn)是客戶永遠(yuǎn)需要''最新〃的代碼，因此對已經(jīng)發(fā)布的某個(gè)分支進(jìn)行維護(hù)的情況很少出現(xiàn)(在測試的時(shí)候會(huì)出現(xiàn))。而且發(fā)布的方法和產(chǎn)品的發(fā)布也不一樣。產(chǎn)品的發(fā)布，只要把發(fā)布分支上的代碼編譯成安裝盤就可以了，而外包的發(fā)布往往是把上一次發(fā)布和這一次發(fā)布之間發(fā)生變化的代碼送給客戶。如果每次發(fā)布都是一個(gè)分支的話，將會(huì)出現(xiàn)兩個(gè)分支上的比較。強(qiáng)大的版本控制工具當(dāng)然支持這種比較，但是很多版本工具不支持分支之間的比較，而只支持分支內(nèi)的不同版本之間的比較。因此為了避免發(fā)布方法受工具的限制，就要避免出現(xiàn)分支間比較的情況。針對外包開發(fā)的特殊情況，只有采用另外一種分支管理策略。3.2主干用來發(fā)布與第一種分支策略正好相反，主干上永遠(yuǎn)是穩(wěn)定版本，可以隨時(shí)發(fā)布。bug的修改和新功能的增加，全部在分支上進(jìn)行。而且每個(gè)bug和新功能都有不同的開發(fā)分支，完全分離。而對主干上的每一次發(fā)布都做一個(gè)標(biāo)記而不是分支。分支上的開發(fā)和測試完畢以后才合并到主干。這種發(fā)布方法的好處是每次發(fā)布的內(nèi)容調(diào)整起來比較容易。如果某個(gè)新功能或者bug在下一次發(fā)布之前無法完成，就不可能合并到主干，也就不會(huì)影響其他變更的發(fā)布。另外，每個(gè)分支的生命期比較短，唯一長期存在的就是主干，這樣每次合并的風(fēng)險(xiǎn)很小。每次發(fā)布之前，只要比較主干上的最新版本和上一次發(fā)布的版本就能夠知道這次發(fā)布的文件范圍了。這種發(fā)布模式也有缺點(diǎn)。如果某個(gè)開發(fā)分支因?yàn)楣δ鼙容^復(fù)雜，或者應(yīng)發(fā)布計(jì)劃的要求而長期沒有合并到主干上，很可能在最后合并的時(shí)候出現(xiàn)沖突。因此必須時(shí)刻注意分支離開主干的時(shí)間。如果有的分支確實(shí)因?yàn)樘厥獾男枰仨氶L期存在，那就必須定期把主干的更新往這個(gè)分支上合并。為了減少這種合并發(fā)生的次數(shù)，并且限定合并的范圍，要為每次發(fā)布預(yù)先建立一個(gè)發(fā)布分支，然后所有的開發(fā)分支根據(jù)自己的發(fā)布計(jì)劃向各個(gè)發(fā)布分支合并。當(dāng)下一次發(fā)布的分支上已經(jīng)集成了所有的變更并且測試完畢以后，把這個(gè)發(fā)布分支內(nèi)容合并到主干，發(fā)布主干，然后鎖定或者刪除這個(gè)分支。然后把主干上的所有更新合并到后面幾個(gè)發(fā)布分支里面去。外包項(xiàng)目的發(fā)布周期一般都比較短，往往客戶驗(yàn)收測試的周期就是發(fā)布周期。所以這種方法就夠用了。如果發(fā)布周期很長，各個(gè)發(fā)布分支之間還要定期的從前向后合并。這種發(fā)布方法還有一個(gè)缺點(diǎn)就是測試。不像第一種分支策略，發(fā)布的分支就是測試的分支。這種發(fā)布模式的測試分支往往是各個(gè)發(fā)布分支，在正式發(fā)布之前才把下一個(gè)發(fā)布分支上的更新合并到主干，這就引入了合并出錯(cuò)的風(fēng)險(xiǎn)，而主干上的程序是沒有經(jīng)過測試的。幸好從這個(gè)發(fā)布模式上看，下一個(gè)發(fā)布分支的合并基礎(chǔ)應(yīng)該和主干上一次發(fā)布內(nèi)容相同，所以引入合并錯(cuò)誤的風(fēng)險(xiǎn)很低。還有一種建議就是不設(shè)置主干，下一個(gè)發(fā)布分支就是主干，直接發(fā)布下一個(gè)發(fā)布分支的變更內(nèi)容，然后把變更合并到再下一個(gè)發(fā)布分支上去。以此類推。3.3注意事項(xiàng)1)做分支上做開發(fā)的時(shí)候，必須定期使分支與主干同步，避免開發(fā)完成后合并(merge)回主干時(shí)出現(xiàn)嚴(yán)重沖突(confict)；2） 進(jìn)行合并前，處理掉工作副本上的所有本地修改，方便合并失敗時(shí)進(jìn)行回滾（revert）；3） 進(jìn)行合并時(shí)，特別注意新增/刪除操作，因?yàn)楹芏鄾_突都是這類操作引起的；4） 完成一個(gè)分支的功能并合并回主干后，拋棄該分支，后續(xù)其它功能的開發(fā)使用新建的分支。當(dāng)然，也有辦法繼續(xù)使用該分支；5） 輔助文檔是必需的。為了觀察分支的創(chuàng)建和合并的過程，至少需要一份類似泳道圖的文檔標(biāo)記每一次分支創(chuàng)建和合并的過程；6） 開發(fā)分支往主干或者發(fā)布分支合并的次數(shù)應(yīng)該盡可能少。一般來講應(yīng)該在單體測試結(jié)束合并到主干或者發(fā)布分支，然后進(jìn)行結(jié)合測試。如果結(jié)合測試?yán)锇l(fā)現(xiàn)bug不應(yīng)該在原來的開發(fā)分支上繼續(xù)修改，而應(yīng)該創(chuàng)建新的分支進(jìn)行修改；7） 分支創(chuàng)建和合并的log必須規(guī)范。便于以后查找。基本的log信息應(yīng)該包括從哪個(gè)分支的哪個(gè)版本創(chuàng)建分支;把哪個(gè)分支的從哪版本到哪個(gè)版本范圍內(nèi)的變更合并到了哪個(gè)分支的哪個(gè)版本，合并后的版本號(hào)。這些信息有一些是版本控制工具本身可以很方便查找到的，就可以省略4操作步驟在代碼庫中創(chuàng)建trunk、branches、tags目錄，分別為主干、分支和標(biāo)記，這樣的布局是為了更清晰的區(qū)別主線、分支和標(biāo)記三者的位置。在主干上提交代碼，到可發(fā)布的程度時(shí)，創(chuàng)建分支。為便于比較結(jié)果，我們在主干中上傳一個(gè)文件readme.txt（版本為659）：4.1創(chuàng)建分支（標(biāo)記）將主干trunk簽出（checkout）到本地，在本地checkout的trunk目錄上單擊鼠標(biāo)右鍵，在彈出菜單中選擇“TortoiseSVN”—“Branch/tag...”在下圖彈出的窗口中，將“ToURL”指向branches目錄并輸入分支的具體目錄名。默認(rèn)的目標(biāo)URL將會(huì)是你當(dāng)前工作拷貝所處的源URL，必須給分支/標(biāo)記編輯一個(gè)新路徑。SVN不會(huì)自動(dòng)遞歸創(chuàng)建目錄，要自己先創(chuàng)建好父目錄。比如想創(chuàng)建分支/branches/V1.0，那么V1.0可以不用自己創(chuàng)建，但是/branches要先創(chuàng)建好。這里是branches/V1.0，我們即將創(chuàng)建的分支便存放于此處，點(diǎn)擊OK上圖中紅色方框內(nèi)Createcopyrevisionintherepository下的選項(xiàng)：uHEADrevisionintherepository拷貝當(dāng)前主干中的最新版本。不需要從你的工作副本中傳輸任何數(shù)據(jù)，這個(gè)分支的建立是非?？斓?。uSpecificrevisioninrepository拷貝主干中的某個(gè)指定版本。假如你在上周發(fā)布了項(xiàng)目時(shí)忘記了做標(biāo)記，這將非常有用。如果記不起來版本號(hào)，通過點(diǎn)擊鼠標(biāo)右鍵來顯示版本日志，同時(shí)從這里選取版本號(hào)。和上次一樣不需要從你的工作副本中傳輸任何數(shù)據(jù)，這個(gè)分支建立起來是非?？斓?。uWorkingcopy：新的分支是一個(gè)完全等同于你的本地工作副本的一個(gè)拷貝。如果你更新了一些文件到你的工作副本的某個(gè)舊版本里，或者你在本地做出了修改，這些改變將準(zhǔn)確無誤地進(jìn)入拷貝中。自然而然地這種綜合的標(biāo)記會(huì)包含正在從工作副本傳輸?shù)桨姹編熘械臄?shù)據(jù)，如果這些數(shù)據(jù)還不存在的話。選擇完畢后單擊【OK】按鈕，則分支創(chuàng)建完畢。再次查看配置庫，可以看到剛才創(chuàng)建的分支中包括主干中的文檔“readme.txt”，版本為659，同主干一致。標(biāo)記的創(chuàng)建方法同分支一樣，都是對主干的拷貝操作（實(shí)際是對某一版本的鏈接）。4.2合并分支分支用來維護(hù)獨(dú)立的開發(fā)支線，在一些階段，你可能需要將分支上的修改合并到最新版本，或者將最新版本的修改合并到分支為便于比較結(jié)果，我們修改分支中的readme文件（此時(shí)版本為664），同時(shí)添加一個(gè)文件：如果想將分支合并到主干上，在本地checkout出的主干（trunk）目錄上單擊鼠標(biāo)右鍵，在彈出菜單中選擇''TortoisesSVN'J“Merge”在彈出的“Merge"菜單中選擇類別：在“URLtomergeform’輸入框中選擇分支的URL，在“Reverserangetomerge"填入版本，可點(diǎn)擊【showlog】按鈕選擇需要合并的版本。需要注意的是Merge并非字面上所示的將兩個(gè)分支歸并到一起，而是diff-and-apply的意思，比較兩個(gè)分支的差異并歸并差異。輸入完畢后單擊【Next］：選擇合并選項(xiàng)后（^'Comparewhitespaces”），單擊【Merge］，完成合并操作。如果在合并過程中發(fā)生沖突，SVN會(huì)進(jìn)行提示：進(jìn)行合并后，在本地的trunk目錄會(huì)顯示以下文件：沖突的文件圖標(biāo)中會(huì)有一個(gè)嘆號(hào)，同時(shí)系統(tǒng)自動(dòng)生成3個(gè)文件：ureadme.txt為合并前主干中的版本ureadme.txt.merge-left.r.664：為664版本，即創(chuàng)建分支時(shí)主干中的版本ureadme.txt.merge-right.r665：為665版本，即合并前分支中的版本可以直接打開文件進(jìn)行手動(dòng)修改，沖突的內(nèi)容會(huì)以議<<<<<<< >>>>