1、版本管理危機    起始階段：    項目的開始，項目組只有從第三方獲取的類庫、具備編程知識的程序員和PM（項目經理）。由于成員數量不少，使用簡單共享方式的版本管理往往難以勝任，某些人往往會因為新功能的需要或者無意將一些代碼改得面目全非，無從追蹤。我們需要一個簡單的版本管理工具，比如Visual Source Safe，每個人在修改代碼之前要求先將代碼文件標記為“檢出”狀態，每一次“檢入”代碼都在服務器上生成一個新的版本。好了，所有的代碼都有了版本記錄，我們可以查看代碼的演進過程，對任何兩個版本進行比較，也可以輕松的獲取到早先的版本。

2、    開始迭代：    由于客戶的要求，項目開始進行簡單的迭代。PM要求所有人員檢入可以工作的代碼。然后開始執行構建。第一次全部構建的過程可能并不順利，因為有人修改了A組件導致了依賴A組件的B組件不能正常工作了。當然這個不難解決，我們需要對成員進行培訓，要求每個人在檢入代碼前保證所有的構建都是成功的。這很湊效，雖然每次構建要耗費不少時間。編譯的錯誤很容易發現，但是邏輯的錯誤卻沒有那么簡單了。不過，到現在為止，這個并不太重要，畢竟項目剛剛開始迭代，在給客戶演示的時候偶爾崩潰也是可以忍受的。    版本建立

3、：    隨著項目第一次交付期的臨近，PM決定停止新特性的開發，確定1.0版本。并且將這個版本發布SIT（系統集成測試）。剛剛SIT測試的時候，大家都忙于修改自己的代碼中的BUG，忙得不亦樂乎。慢慢的，BUG數量曲線開始趨于平滑。很多人開始覺的可以將當前版本發布，從而可以投入精力進行新特性的開發了。PM也這么認為，因為從需求跟蹤矩陣的情況看，還有許多的工作量，客戶會要求在第二次交付（2.0.x版本）的時候看到剩下的需求都已經實現。為了不影響1.0.x版本的構建，PM下令所有人可以在本地編輯代碼以添加新特性，但是不得檢入版本機，唯一允許被檢入版本機的是修改BUG的代

4、碼。這在一段時間里看起來工作得不錯，知道有一天，小王發現他在 a.java 文件中添加和編輯了許多的新特性相關的代碼，但是 現在要命的是發現了一個跟 a.java 相關的BUG。冥思苦想，小王決定將a.java先備份起來，然后撤銷檢出，ok，回到1.0.x的代碼了，在a.java中修改了一通，檢入了，很幸運，居然沒有引起問題。小王開始將原先備份的 a.java和修改過BUG的a.java中的更改進行合并，合并的結果將產生一個新的a.java文件，這個文件沒有了已經發現的BUG，而且包含了新特性的代碼。由于小王是高手，所編寫的代碼遵從了SRP(單一職責原則)，所以小王的合并并沒有耗費縮少時間。但

5、是接下來的時間里，小王又發現b.java,c.java,d.javax.java需要進行這種手工的合并，每一次合并，他都要將文件預先備份起來。而且，因為在1.0.x穩定運行之前，小王不得檢入自己的代碼，因此小王擔心，如果自己的硬盤崩潰，小王也為不能夠使用其它人編寫的新特性代碼而感到無比郁悶。PM也意識到這種情況，在一個晚上的權衡之后，PM決定在版本服務器上建立了2.0.x的目錄，將1.0.x的代碼拷貝到這里來。Ok，所有的新特性的開發在2.0.x中進行，所有的BUG修改在1.0.x和2.0.x中同時進行。這真是一個不錯的主意。但是，過不了多久，項目組就被頻繁的拷貝粘貼折騰的死去活來，代碼的修改

6、沒有辦法被有效跟蹤則更是讓人傷透了腦筋。典型的版本管理難題    看完了上篇，我們對于多分支開發容易產生的問題應該有了一些基本的了解吧。事實上，通常，并行開發的版本管理面臨以下幾個典型的難題：        如何保證新版本開發與BugFix同時進行?也就是要求修改過的BUG不能存在于新版本中。        如何保證兩個新版本并行開發？可能的情況是兩個完全不同的版本，或者一個是另外一個基礎。   

7、     如何保證版本的發布不受開發人員無意的代碼檢入影響?     不再拐彎抹角了，解決這三個難題的答案是使用分支（這里涉及到一個著名的版本管理工具ClearCase，分支正是其中的重要工具和概念）。要理解分支必須同時理解其他的術語，比如標簽、視圖。本文不打算詳細地描述基礎的概念，相關的概念可以參考ClearCase的文檔。圖1    上面是一棵版本樹，形象地記載了一個文件的版本變化情況。    其中，1、2、3是不同的版本；Main、Ver2.0就是分

8、支；Release1023和Ver2.0Begin則是標簽，標簽就像是打在代碼版本上的標記；視圖就是由分支類型、標簽名稱、獲取規則動態的決定的代碼橫截面。可以建立Main分支的視圖，在這個視圖中我們就看不到Ver2.0分支中的任何代碼修改；也可以建立Ver2.0分支的視圖，在這個視圖中我們可以看到Ver2.0分支的最新代碼和未在Ver2.0分支中產生修改的Main分支中位于Ver2.0Begin標簽處的代碼。    開發人員總是習慣工作于一個視圖上。那看看解決第一個問題的辦法。圖2    1. 建立用于修改Bug的分支視圖，在此視圖上

9、進行修改。    2. 將在BugFix上修改的代碼合并到主分支中，合并產生新的版本3，移動Ver2.0Begin標簽到版本3，Ver2.0分支自動獲取到修復Bug以后的代碼，同時，主分支上的Bug也得到了修正。    3. 如果此時代碼已經在Ver2.0上發生了變化，則需要執行另外一個合并，將更改合并到Ver2.0中。但幸運的是，大多數時候不會在BugFix之前修改Ver2.0的代碼。    這樣做我們至少收獲了幾個附加的好處：      &#

10、160; 我們獲得了從Main分支發布穩定版本的能力；        我們獲得了從Ver2.0分支發布最新預覽版的能力；        開發人員的檢入檢出不影響版本發布；        版本管理員可以對Main分支進行鎖定等控制，防止其他人員越權或者意外的修改Main分支的代碼。版本的強制控制和版本合并    版本需要強制控制的幾種常見場景： &#

11、160;  1. 要轉產或者上市了，不希望開發者隨意的代碼檢入影響到產品的質量和穩定性。    2. 已經轉產了，希望控制Bug的修改，不希望開發者隨意的代碼檢入影響到補丁（包）的發布。    版本強制控制的手段包括：    1. 將需要保護的分支鎖定（僅允許版本管理員修改），打上Release標簽。    2. 讓開發者在以Release標簽為基線的分支上進行開發。    3. 登記開發者在以Release標簽為基線的分支上的代碼修改

12、動作。    4. 在以Release標簽為基線的分支上發布版本進行集成測試。    5. 對于集成測試通過的代碼修改，通過版本合并手段合并到被保護的分支上。    上面提到了版本合并。事實上，版本合并也有如下的幾種常見情景：    1. 修改了Bug ，需要合并到基線版本中，以便可以發布穩定版本。圖3    2. 修改了Bug，需要合并到其他正在開發新功能的代碼中。圖4    3. 修改了Bug，導致基線發生改變，

13、希望將改變體現到已經發生了改變的2.0版本中。圖5    4. 1.1版本開發完成，1.0版不再維護，希望將1.1版本合并到基線版本中，作為以后開發新版本的基礎.圖6流動的基線    基線所有代碼起始版本的集合。如果沒有并行開發，基線也許就是版本機上的一個簡單文件夾。如果進行并行開發，那么基線就是具有了指定標簽的版本的集合。    在進行并行開發的時候，我們希望基線是流動的，會隨著我們的期望變化。比如，我們在1.1版本捉蟲的時候開始了2.0版本的開發，我們希望2.0的起始版本保持與1.1的最終版本一致。這

14、里基于一點假設，假設2.0版本不回全面改寫1.1版本的代碼，而是小部分的改動。這種假設依賴于良好的設計。在擴展功能的時候，對原有代碼的改動盡量少。假設我們有A1-A10共10個文件，在2.0版本中，為了增加新的功能，我們改動了A9，A10兩個文件，在1.1版Preview以后，1.1版本中因為修改Bug，又改動了A8，A9兩個文件。我們要使2.0版本的初始代碼包含1.1版本的最總代碼，我們需要做的事情就是將A8按照上篇所介紹的第一種合并場景進行合并，即合并到基線中（簡單的移動基線標簽），而A9文件，則除了要合并到基線中意外，還要進行上篇所介紹的的第三種場景的合并，即將基線的變化合并到已經發生改

15、變的2.0版本中（移動基線標簽并進行合并）。通常，基線變更涉及的文件數應該盡量少。    這就是流動的基線。因基線的變更需要許多人工判斷的介入，所以基線應該是穩定經受考驗的版本。我們要保證基線的穩定性，不是所有的人都可以隨意改變基線，基線也不是每時每刻不斷的變化（上篇已經介紹了版本的強制控制）。事實上，基線的變化越少越好。通?；€發生變化也存在常見的場景。    1. 1.1版本Preview。如果1.1版本是在分支上進行開發的，那么VM希望將分支上的代碼完全合并到主分支上，以避免開發者的代碼檢入影響版本的穩定性和分支的長期存在對于版本服務器性能的影響。這種合并的工