版本管理危機(jī)

1、版本管理危機(jī) 起始階段： 項(xiàng)目的開始，項(xiàng)目組只有從第三方獲取的類庫(kù)、具備編程知識(shí)的程序員和PM（項(xiàng)目經(jīng)理）。由于成員數(shù)量不少，使用簡(jiǎn)單共享方式的版本管理往往難以勝任，某些人往往會(huì)因?yàn)樾鹿δ艿男枰蛘邿o意將一些代碼改得面目全非，無從追蹤。我們需要一個(gè)簡(jiǎn)單的版本管理工具，比如Visual Source Safe，每個(gè)人在修改代碼之前要求先將代碼文件標(biāo)記為“檢出”狀態(tài)，每一次“檢入”代碼都在服務(wù)器上生成一個(gè)新的版本。好了，所有的代碼都有了版本記錄，我們可以查看代碼的演進(jìn)過程，對(duì)任何兩個(gè)版本進(jìn)行比較，也可以輕松的獲取到早先的版本。 開始迭代： 由于客戶的要求，項(xiàng)目開始進(jìn)行簡(jiǎn)單的迭代。PM要求所有人員檢

2、入可以 HYPERLINK javascript:; 工作的代碼。然后開始執(zhí)行構(gòu)建。第一次全部構(gòu)建的過程可能并不順利，因?yàn)橛腥诵薷牧薃組件導(dǎo)致了依賴A組件的B組件不能正常工作了。當(dāng)然這個(gè)不難解決，我們需要對(duì)成員進(jìn)行培訓(xùn)，要求每個(gè)人在檢入代碼前保證所有的構(gòu)建都是成功的。這很湊效，雖然每次構(gòu)建要耗費(fèi)不少時(shí)間。編譯的錯(cuò)誤很容易發(fā)現(xiàn)，但是邏輯的錯(cuò)誤卻沒有那么簡(jiǎn)單了。不過，到現(xiàn)在為止，這個(gè)并不太重要，畢竟項(xiàng)目剛剛開始迭代，在給客戶演示的時(shí)候偶爾崩潰也是可以忍受的。 版版本建立立： 隨隨著項(xiàng)目目第一次次交付期期的臨近近，PMM決定停停止新特特性的開開發(fā)，確確定1.0版本本。并且且將這個(gè)個(gè)版本發(fā)發(fā)布SIIT

3、（系系統(tǒng)集成成 HYPERLINK javascript:; 測(cè)試）。剛剛剛SIIT測(cè)試試的時(shí)候候，大家家都忙于于修改自自己的代代碼中的的 HYPERLINK javascript:; BUGG，忙得得不亦樂樂乎。慢慢慢的，BBUG數(shù)數(shù)量曲線線開始趨趨于平滑滑。很多多人開始始覺的可可以將當(dāng)當(dāng)前版本本發(fā)布，從從而可以以投入精精力進(jìn)行行新特性性的開發(fā)發(fā)了。PPM也這這么認(rèn)為為，因?yàn)闉閺男枨笄蟾櫨鼐仃嚨那榍闆r看，還還有許多多的工作作量，客客戶會(huì)要要求在第第二次交交付（22.0.x版本本）的時(shí)時(shí)候看到到剩下的的需求都都已經(jīng)實(shí)實(shí)現(xiàn)。為為了不影影響1.0.xx版本的的構(gòu)建，PPM下令令所有人人可以在在本

4、地編編輯代碼碼以添加加新特性性，但是是不得檢檢入版本本機(jī)，唯唯一允許許被檢入入版本機(jī)機(jī)的是修修改BUUG的代代碼。這這在一段段時(shí)間里里看起來來工作得得不錯(cuò)，知知道有一一天，小小王發(fā)現(xiàn)現(xiàn)他在 a.jjavaa 文件件中添加加和編輯輯了許多多的新特特性相關(guān)關(guān)的代碼碼，但是是 現(xiàn)在在要命的的是發(fā)現(xiàn)現(xiàn)了一個(gè)個(gè)跟 aa.jaava 相關(guān)的的BUGG。冥思思苦想，小小王決定定將a.javva先備備份起來來，然后后撤銷檢檢出，ook，回回到1.0.xx的代碼碼了，在在a.jjavaa中修改改了一通通，檢入入了，很很幸運(yùn)，居居然沒有有引起問問題。小小王開始始將原先先備份的的 a.javva和修修改過BBUG的

5、的a.jjavaa中的更更改進(jìn)行行合并，合合并的結(jié)結(jié)果將產(chǎn)產(chǎn)生一個(gè)個(gè)新的aa.jaava文文件，這這個(gè)文件件沒有了了已經(jīng)發(fā)發(fā)現(xiàn)的BBUG，而而且包含含了新特特性的代代碼。由由于小王王是高手手，所編編寫的代代碼遵從從了SRRP(單單一職責(zé)責(zé)原則)，所以以小王的的合并并并沒有耗耗費(fèi)縮少少時(shí)間。但但是接下下來的時(shí)時(shí)間里，小小王又發(fā)發(fā)現(xiàn)b.javva,cc.jaava,d.jjavaax.javva需要要進(jìn)行這這種手工工的合并并，每一一次合并并，他都都要將文文件預(yù)先先備份起起來。而而且，因因?yàn)樵?1.0.x穩(wěn)定定運(yùn)行之之前，小小王不得得檢入自自己的代代碼，因因此小王王擔(dān)心，如如果自己己的硬盤盤崩潰，小

6、小王也為為不能夠夠使用 HYPERLINK javascript:; 其其它人編編寫的新新特性代代碼而感感到無比比郁悶。PPM也意意識(shí)到這這種情況況，在一一個(gè)晚上上的權(quán)衡衡之后，PPM決定定在版本本服務(wù)器器上建立立了2.0.xx的目錄錄，將11.0.x的代代碼拷貝貝到這里里來。OOk，所所有的新新特性的的開發(fā)在在2.00.x中中進(jìn)行，所所有的BBUG修修改在11.0.x和22.0.x中同同時(shí)進(jìn)行行。這真真是一個(gè)個(gè)不錯(cuò)的的主意。但但是，過過不了多多久，項(xiàng)項(xiàng)目組就就被頻繁繁的拷貝貝粘貼折折騰的死死去活來來，代碼碼的修改改沒有辦辦法被有有效跟蹤蹤則更是是讓人傷傷透了腦腦筋。典型的版本本管理難難題 看

7、看完了上上篇，我我們對(duì)于于多分支支開發(fā)容容易產(chǎn)生生的問題題應(yīng)該有有了一些些基本的的了解吧吧。事實(shí)實(shí)上，通通常，并并行開發(fā)發(fā)的版本本管理面面臨以下下幾個(gè)典典型的難難題： 如何何保證新新版本開開發(fā)與BBugFFix同同時(shí)進(jìn)行行?也就就是要求求修改過過的BUUG不能能存在于于新版本本中。 如何何保證兩兩個(gè)新版版本并行行開發(fā)？可能的的情況是是兩個(gè)完完全不同同的版本本，或者者一個(gè)是是另外一一個(gè)基礎(chǔ)礎(chǔ)。 如何保保證版本本的發(fā)布布不受開開發(fā)人員員無意的的代碼檢檢入影響響? 不再拐拐彎抹角角了，解解決這三三個(gè)難題題的答案案是使用用分支（這這里涉及及到一個(gè)個(gè)著名的的版本管管理工具具CleearCCasee，分支

8、支正是其其中的重重要工具具和概念念）。要要理解分分支必須須同時(shí)理理解 HYPERLINK javascript:; 其他他的術(shù)語(yǔ)語(yǔ)，比如如標(biāo)簽、視視圖。本本文不打打算詳細(xì)細(xì)地描述述基礎(chǔ)的的概念，相相關(guān)的概概念可以以參考CCleaarCaase的的文檔。圖1 上上面是一一棵版本本樹，形形象地記記載了一一個(gè)文件件的版本本變化情情況。 其中，11、2、33是不同同的版本本；Maain、VVer22.0就就是分支支；Reeleaase110233和Veer2.0Beeginn則是標(biāo)標(biāo)簽，標(biāo)標(biāo)簽就像像是打在在代碼版版本上的的標(biāo)記；視圖就就是由分分支類型型、標(biāo)簽簽名稱、獲獲取規(guī)則則動(dòng)態(tài)的的決定的的代碼橫橫

9、截面。可可以建立立Maiin分支支的視圖圖，在這這個(gè)視圖圖中我們們就看不不到Veer2.0分支支中的任任何代碼碼修改；也可以以建立VVer22.0分分支的視視圖，在在這個(gè)視視圖中我我們可以以看到VVer22.0分分支的最最新代碼碼和未在在Verr2.00分支中中產(chǎn)生修修改的MMainn分支中中位于VVer22.0BBegiin標(biāo)簽簽處的代代碼。 開發(fā)人人員總是是習(xí)慣工工作于一一個(gè)視圖圖上。那那看看解解決第一一個(gè)問題題的辦法法。圖2 11. 建建立用于于修改BBug的的分支視視圖，在在此視圖圖上進(jìn)行行修改。 2. 將在BugFix上修改的代碼合并到主分支中，合并產(chǎn)生新的版本3，移動(dòng)Ver2.0B

10、egin標(biāo)簽到版本3，Ver2.0分支自動(dòng)獲取到修復(fù)Bug以后的代碼，同時(shí)，主分支上的Bug也得到了修正。 3. 如果此時(shí)代碼已經(jīng)在Ver2.0上發(fā)生了變化，則需要執(zhí)行另外一個(gè)合并，將更改合并到Ver2.0中。但幸運(yùn)的是，大多數(shù)時(shí)候不會(huì)在BugFix之前修改Ver2.0的代碼。 這樣做我們至少收獲了幾個(gè)附加的好處： 我們獲得了從Main分支發(fā)布穩(wěn)定版本的能力； 我們獲得了從Ver2.0分支發(fā)布最新預(yù)覽版的能力； 開發(fā)人員的檢入檢出不影響版本發(fā)布； 版本管理員可以對(duì)Main分支進(jìn)行鎖定等控制，防止其他人員越權(quán)或者意外的修改Main分支的代碼。版本的強(qiáng)制制控制和和版本合合并 版版本需要要強(qiáng)制控控制

11、的幾幾種常見見場(chǎng)景： 1. 要轉(zhuǎn)轉(zhuǎn)產(chǎn)或者者上市了了，不希希望開發(fā)發(fā)者隨意意的代碼碼檢入影影響到產(chǎn)產(chǎn)品的質(zhì)質(zhì)量和穩(wěn)穩(wěn)定性。 2. 已經(jīng)轉(zhuǎn)產(chǎn)了，希望控制Bug的修改，不希望開發(fā)者隨意的代碼檢入影響到補(bǔ)?。ò┑陌l(fā)布。 版本強(qiáng)制控制的手段包括： 1. 將需要保護(hù)的分支鎖定（僅允許版本管理員修改），打上Release標(biāo)簽。 2. 讓開發(fā)者在以Release標(biāo)簽為基線的分支上進(jìn)行開發(fā)。 3. 登記開發(fā)者在以Release標(biāo)簽為基線的分支上的代碼修改動(dòng)作。 4. 在以Release標(biāo)簽為基線的分支上發(fā)布版本進(jìn)行集成測(cè)試。 5. 對(duì)于集成測(cè)試通過的代碼修改，通過版本合并手段合并到被保護(hù)的分支上。 上面提到了

12、版本合并。事實(shí)上，版本合并也有如下的幾種常見情景： 1. 修改了Bug ，需要合并到基線版本中，以便可以發(fā)布穩(wěn)定版本。圖3 22. 修修改了BBug，需需要合并并到其他他正在開開發(fā)新功功能的代代碼中。圖4 33. 修修改了BBug，導(dǎo)導(dǎo)致基線線發(fā)生改改變，希希望將改改變體現(xiàn)現(xiàn)到已經(jīng)經(jīng)發(fā)生了了改變的的2.00版本中中。圖5 44. 11.1版版本開發(fā)發(fā)完成，11.0版版不再維維護(hù)，希希望將11.1版版本合并并到基線線版本中中，作為為以后開開發(fā)新版版本的基基礎(chǔ).圖6流動(dòng)的基線線 基基線所有代代碼起始始版本的的集合。如如果沒有有并行開開發(fā)，基基線也許許就是版版本機(jī)上上的一個(gè)個(gè)簡(jiǎn)單文文件夾。如如果進(jìn)行

13、行并行開開發(fā)，那那么基線線就是具具有了指指定標(biāo)簽簽的版本本的集合合。 在在進(jìn)行并并行開發(fā)發(fā)的時(shí)候候，我們們希望基基線是流流動(dòng)的，會(huì)會(huì)隨著我我們的期期望變化化。比如如，我們們?cè)?.1版本本捉蟲的的時(shí)候開開始了22.0版版本的開開發(fā)，我我們希望望2.00的起始始版本保保持與11.1的的最終版版本一致致。這里里基于一一點(diǎn)假設(shè)設(shè)，假設(shè)設(shè)2.00版本不不回全面面改寫11.1版版本的代代碼，而而是小部部分的改改動(dòng)。這這種假設(shè)設(shè)依賴于于良好的的設(shè)計(jì)。在在擴(kuò)展功功能的時(shí)時(shí)候，對(duì)對(duì)原有代代碼的改改動(dòng)盡量量少。假假設(shè)我們們有A11-A110共110個(gè)文文件，在在2.00版本中中，為了了增加新新的功能能，我們們改動(dòng)

14、了了A9，AA10兩兩個(gè)文件件，在11.1版版Preevieew以后后，1.1版本本中因?yàn)闉樾薷腂Bug，又又改動(dòng)了了A8，AA9兩個(gè)個(gè)文件。我我們要使使2.00版本的的初始代代碼包含含1.11版本的的最總代代碼，我我們需要要做的事事情就是是將A88按照上上篇所介介紹的第第一種合合并場(chǎng)景景進(jìn)行合合并，即即合并到到基線中中（簡(jiǎn)單單的移動(dòng)動(dòng)基線標(biāo)標(biāo)簽），而而A9文文件，則則除了要要合并到到基線中中意外，還還要進(jìn)行行上篇所所介紹的的的第三三種場(chǎng)景景的合并并，即將將基線的的變化合合并到已已經(jīng)發(fā)生生改變的的2.00版本中中（移動(dòng)動(dòng)基線標(biāo)標(biāo)簽并進(jìn)進(jìn)行合并并）。通通常，基基線變更更涉及的的文件數(shù)數(shù)應(yīng)該盡盡量少。 這就是流動(dòng)的基線。因基線的變更需要許多人工判斷的介入，所以基線應(yīng)該是穩(wěn)定經(jīng)受考驗(yàn)的版本。我們要保證基線的穩(wěn)定性，不是所有的人都可以隨意改變基線，基線也不是每時(shí)每刻不斷的變化（上篇已經(jīng)介紹了版本的強(qiáng)制控制）。事實(shí)上，基線的變化越少越好。通?；€發(fā)生變化也存在常見的場(chǎng)景。 1. 1.1版本Preview。如果1.1版本是在分支上進(jìn)行開發(fā)的，那么VM希望將分支上的代碼完全合并到主分