看完了上篇，我們對于多分支開發(fā)容易產(chǎn)生的問題應該有了一些基本的了解吧。事實上，通常，并行開發(fā)的版本管理面臨以下幾個典型的難題

 　　◆　如何保證新版本開發(fā)與BugFix同時進行?也就是要求修改過的BUG不能存在于新版本中題

 　　◆　如何保證兩個新版本并行開發(fā)?可能的情況是兩個完全不同的版本，或者一個是另外一個基礎題

 　　◆　 如何保證版本的發(fā)布不受開發(fā)人員無意的代碼檢入影響? 

 　　不再拐彎抹角了，解決這三個難題的答案是使用分支（這里設計到一個著名的版本管理工具-ClearCase,分支正是其中的重要工具和概念）。

　　[OK，這里有個術語，就是分支。要理解分支必須同時理解其他的術語，比如說標簽、視圖。本文不打算詳細的描述基礎的概念，相關的概念可以參考ClearCase（一個強大的版本管理工具）的文檔。]

   上面是一顆版本樹，形象的記載了一個文件的版本變化情況。

　　◆其中1、2、3是不同的版本，

　　◆Main，Ver2.0就是分支。

　　◆Release1023和Ver2.0Begin則是標簽，標簽就像是打在代碼版本上的標記。

　　◆視圖就是由分支類型、標簽名稱、獲取規(guī)則動態(tài)的決定的代碼橫截面。我可以建立Main分支的視圖，在這個視圖中我就看不到Ver2.0分支中的任何代碼修改，我也可以建立Ver2.0分支的視圖，在這個視圖中我們可以看到Ver2.0分支的最新代碼和未在Ver2.0分支中產(chǎn)生修改的Main分支中位于Ver2.0Begin標簽處的代碼。開發(fā)人員總是習慣工作于一個視圖上。

       OK，那看看解決第一個問題的辦法。

　　建立用于修改BUG的分支視圖，在此視圖上進行修改將在BugFix上修改的代碼合并到主分支中，合并產(chǎn)生新的版本3，移動Ver2.0Begin標簽到版本3，Ver2.0分支自動獲取到修復BUG以后的代碼，同時，主分支上的BUG也得到了修正如果此時代碼已經(jīng)在Ver2.0上發(fā)生了變化，則需要執(zhí)行另外一個合并，將更改合并到Ver2.0中。但是幸運的是，大多數(shù)時候不會在BugFix之前修改Ver2.0的代碼。
 
   這樣做我們至少收獲了幾個附加的好處

　　◆　我們獲得了從Main分支發(fā)布穩(wěn)定版本的能力

　　◆　我們獲得了從Ver2.0分支發(fā)布最新預覽版的能力

　　◆　開發(fā)人員的檢入檢出不影響版本發(fā)布

　　◆　版本管理員可以對Main分支進行鎖定等控制，防止其他人員越權(quán)或者意外的修改Main分支的代碼