起始階段：

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

　　開始迭代：

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

　　版本建立：

　　 隨著項目第一次交付期的臨近，PM決定停止新特性的開發(fā)，確定1.0版本。并且將這個版本發(fā)布SIT（系統(tǒng)集成測試）。剛剛SIT測試的時候，大家都忙于修改自己的代碼中的BUG，忙得不亦樂乎。慢慢的，BUG數(shù)量曲線開始趨于平滑。很多人開始覺的可以將當(dāng)前版本發(fā)布，從而可以投入精力進(jìn)行新特性的開發(fā)了。PM也這么認(rèn)為，因為從需求跟蹤矩陣的情況看，還有許多的工作量，客戶會要求在第二次交付（2.0.x版本）的時候看到剩下的需求都已經(jīng)實現(xiàn)。為了不影響1.0.x版本的構(gòu)建，PM下令所有人可以在本地編輯代碼以添加新特性，但是不得檢入版本機(jī)，唯一允許被檢入版本機(jī)的是修改BUG的代碼。這在一段時間里看起來工作得不錯，知道有一天，小王發(fā)現(xiàn)他在 a.java 文件中添加和編輯了許多的新特性相關(guān)的代碼，但是 現(xiàn)在要命的是發(fā)現(xiàn)了一個跟 a.java 相關(guān)的BUG。冥思苦想，小王決定將a.java先備份起來，然后撤銷檢出，ok，回到1.0.x的代碼了，在a.java中修改了一通，檢入了，很幸運(yùn)，居然沒有引起問題。小王開始將原先備份的 a.java和修改過BUG的a.java中的更改進(jìn)行合并，合并的結(jié)果將產(chǎn)生一個新的a.java文件，這個文件沒有了已經(jīng)發(fā)現(xiàn)的BUG，而且包含了新特性的代碼。由于小王是高手，所編寫的代碼遵從了SRP(單一職責(zé)原則)，所以小王的合并并沒有耗費(fèi)縮少時間。但是接下來的時間里，小王又發(fā)現(xiàn)b.java,c.java,d.java…x.java需要進(jìn)行這種手工的合并，每一次合并，他都要將文件預(yù)先備份起來。而且，因為在1.0.x穩(wěn)定運(yùn)行之前，小王不得檢入自己的代碼，因此小王擔(dān)心，如果自己的硬盤崩潰，小王也為不能夠使用其它人編寫的新特性代碼而感到無比郁悶。PM也意識到這種情況，在一個晚上的權(quán)衡之后，PM決定在版本服務(wù)器上建立了2.0.x的目錄，將1.0.x的代碼拷貝到這里來。Ok，所有的新特性的開發(fā)在2.0.x中進(jìn)行，所有的BUG修改在1.0.x和2.0.x中同時進(jìn)行。這真是一個不錯的主意。但是，過不了多久，項目組就被頻繁的拷貝粘貼折騰的死去活來，代碼的修改沒有辦法被有效跟蹤則更是讓人傷透了腦筋。