用分支實現交迭

用分支實現交迭

是不是釋出補丁版本這個詞聽起來比交迭這個詞更熟悉一些？釋出補丁版本是交迭的一種。讓我們從這裡開始談起。

繪圖產品SuperPen 1.0版，經過六個月的開發，終於上市！在大筆撈錢的同時，公司正在組織開發2.0版，引入更炫的功能，賣出更好的價錢！研發團隊全體，繼續日夜奮戰。在一派大好形勢下也有些不和諧的聲音，一些使用者抱怨，1.0版裡有這個Bug、那個Bug……雖然公司解釋，這些都會在2.0版裡修復，2.0版會以優惠的價格賣給老使用者。但是，有的使用者堅持認為，應該免費提供對1.0版中的Bug的修復，並且現在就要提供，等不到三個月後2.0版啦。“好吧，好吧，”公司管理層決定，“我們出個1.1版，只包括對1.0版中的Bug的修復，不包括任何新功能。把1.1版免費發放給購買了1.0版的老使用者。他們可別想趁機佔便宜，得到2.0版裡的新功能。”

開會回來，研發經理犯了難。“2.0版的研發工作都開始了一個多月了。已經為實現新功能做了很多新的修改。難道這些都作廢，退到1.0版從頭來？”配置管理工程師卻胸有成竹，“頭兒，我們用那種叫分支的方法，就可以實現1.1版和2.0版同時開發，哪個也不耽誤。”

沒錯，現在是分支大顯身手的時候了。先考查一下現在的情形：主幹上比較古老的部分，是目標為1.0版的研發；主幹上某一點，是1.0版本釋出了。隨後，主幹上開始了目標為2.0版的研發，現在正在向前演進。

為支援1.1版，我們從主幹上1.0版本釋出對應的那一點起，做一個分支，岔出來。這條分支的目標是1.1版，也可能將來1.2版也在這上面。我們把這條分支命名為1.x。在這條分支上，我們修復1.0版使用者發現的各個Bug。一個又一個關於Bug修復的變更集被提交到這條分支上。分支在向前演進。在經歷了若干次整合、測試之後，1.1版在這條分支上正式釋出！

把1.1版稱做補丁版本（Patch Release），是因為1.1版跟1.0版相比，沒有什麼大的變化，主要是一些修修補補。注意補丁還有另外一個含義，不完整的釋出。比如說，安裝某軟體，在用100MB的安裝包安裝後，再安裝一個2MB的漢化補丁，把該軟體的選單都改成方塊兒字。這個意義上的補丁，不是這裡討論的主題。

複用另一條分支上的改動

為1.1版所做的工作和為 2.0版所做的工作，其工作目的不同，其程式碼修改不同，因此用兩條分支來體現。然而，為什麼一定要用分支的方式來實現，而不是用完全獨立的兩個目錄或兩個版本庫來實現呢？主要原因是，分支除了有隔離的功能外，還對共享有比較好的支援。使用分支，便於彼此同步和複用。

理想的情形是，在1.x分支上，從1.0版起到1.1版之間所有的程式碼改動，都應該拿到主幹上，貢獻給2.0版。對於這種情形，可以使用版本控制工具提供的簡單命令，一股腦兒地把改動從1.x分支合併到主幹上來。

以上說的是理想的情形，1.x分支上的全部改動都應該拿到主幹上。在實際專案中，並不是這麼理想的情況。比如有個Bug，在1.1版上的修復，只是臨時性的修復，治標不治本，因為治本的代價太大，需要改動軟體中的一些底層結構。而在2.0版中，軟體的相關底層結構已經最佳化，因此，這個Bug在2.0版中已經不存在了。

對此，比較保險的解決辦法是，對1.x分支上的每一個變更集，均由開發人員做出判斷，是否適合合併到主幹。挑挑揀揀，合適的拿，不合適的不拿。

這是以變更集為基礎的挑選工作。而在有些團隊裡，使用的是以變更請求條目為基礎的挑選工作。這裡的變更請求主要是缺陷修復請求，可能還有少量增強請求。考查所有目標為1.x分支的變更請求，看看是否同樣適用於主幹。如果適合，就把相應的變更集從1.x分支複製到主幹。

有選擇地合併比較保險，但其管理成本也是顯然的。在有些專案中，大家寧可容忍把沒必要合併的改動合併過來，也不願花費可觀的精力去把需要合併的改動挑出來。於是就會使用把1.x分支上的所有改動都拿過來這樣的合併方法，就好像工作在理想情況下。

上面討論的都是從1.x分支到主幹的合併。可能還存在相反方向的合併。比如，如果由於某種原因，一個缺陷先在主幹上修復了。不久又決定要在1.x分支上使用同樣的方式修復該缺陷。這時，就需要個案處理，把對應的變更集從主幹複製到1.x分支上。注意這個方向上的合併不應該成為主流，兩邊都有的缺陷通常應該在1.x分支上先修復，因為1.x分支鄰近釋出，對缺陷修復的需求更緊急。

不論是以上哪種合併方法，執行合併操作時，一般來說，大部分改動可以自動合併到另一個分支上。當然，合併可能產生衝突，比如說某個檔案在兩個分支上都改動了同一行，且改為不同的內容。這就需要人來解決，懂得原始碼語義的人來解決。如果合併是由整合工程師或配置管理工程師主導的，那麼出現合併衝突時，一定要找相關開發人員來解決，不要自己改程式碼。

除了程式碼合併衝突，還可能在編譯時或執行時出現問題。這些問題的本質原因都是，在一條分支上的程式碼修改，是以當時這條分支上的原始碼為基礎的修改，它不一定適合放在另一條分支的末端的原始碼上。如果這樣的問題經常冒出來，嚴重干擾了目標分支上的程式碼質量，那麼就要考慮先對合並過來的改動進行一定的質量保證工作，再最終提交到目標分支。而如果這類問題不多，那麼依靠在目標分支上的（狹義）整合中或整合後的質量保證工作來發現和解決問題就可以了。

什麼時候問題不多，什麼時候問題多？一般來說，新的分支剛建立的時候問題不多，因為兩個分支上的內容差不多。隨著時間的流逝，兩個分支上的內容相差越來越多，這時候把一個變更集從一個分支複製到另一個分支，就會越困難，出現各種問題的可能性就越大。可能需要因此而調整合並的策略，引入更多的檢查。

關於不同分支間合併，還要注意合併的頻率。如果合併工作一直拖著，過了很久之後積攢下大量的合併一起做，那麼合併就會變成一件頭疼的事。一團亂麻，出了問題不好解決。這也是因為大家已經對很久以前的改動不熟悉了，需要更多的時間回憶起來。可以考慮制定流程，每當提交一個變更集到1.x分支後，就要考查是否應該把它合併到主幹。當然，定期地合併也不錯，只要兩次合併的間隔不要太久。

我們這裡談論的分支，可以是廣義上的分支的不同具體形式：可以是狹義的分支，也可以是分散式版本控制工具中的不同的版本庫，或者其他的方法。只要這些方法能夠方便地做到不同（廣義）分支之間的隔離和共享就可以。

本文節選自《未雨綢繆——理解軟體配置管理（第2版）》

董越著

圖書詳細資訊:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-733806