版本

大版分支

在發(fā)布一個穩(wěn)定的版本后，我們會創(chuàng)建一個分支，這是因為我們的人力還需要馬不停蹄的繼續(xù)開發(fā)大量的新版本功能（修改代碼），而客戶使用的是穩(wěn)定版本，但很難說不會有BUG，這個時候我們就可以在這個分支修改BUG，立即交付給客戶。創(chuàng)建一個分支是TFS和很多源代碼管理工具都自帶的功能，可惜很多人不知道，我就啰嗦一下。

在TFS的“源代碼管理資源管理器”中，找到你的產(chǎn)品單元目錄，例如MyProduct，右鍵，選擇“Branch 分支”，出現(xiàn)下面的畫面：

在“Target 目標”的地方鍵入MyProduct-1.0，這樣，就在與MyProduct平級的目錄，建立了一個新目錄：MyProduct-1.0。由于之前已經(jīng)在1.0發(fā)版時打了標簽，所以我這里選擇了這個標簽。點擊OK后，你還需要實際的簽入才能生效。

建立一個平級的目錄的好處是，你可以像以前的工作方式一樣，把這個1.0看成一個新的產(chǎn)品單元，這樣之前定義的流程在分支情況下仍然適用。

當真的需要修改BUG時，你需要到MyProduct-1.0下修訂這個BUG，測試并簽入代碼，與往常沒有什么不一樣，唯一的另外就是，通常這個BUG在當前開發(fā)版本中（在這里例子就是MyProduct）也有，TFS提供了簡便的方法幫助你快速完成MyProduct上此BUG的修訂，可以在MyProduct-1.0/src目錄上點擊右鍵，選擇“Merge 合并”，出現(xiàn)下圖：

在“Source branch 源分支”中選擇穩(wěn)定版本（已經(jīng)修訂BUG的版本），在“Target branch 目標分支”上選擇開發(fā)版本（未修訂Bug的版本），注意，一般我們選擇“Selected changesets 選擇變更集”，而不是“All changes up to a specific version 所有變更”，這樣就僅針對你這個bug修改進行合并，點擊“Next 下一步”。

這里你能看見所有未合并的變更集，選擇你的變更集，然后下一步，最后完成。重新回到MyProduct對應(yīng)的MyCode所在目錄，你會發(fā)現(xiàn)TFS自動簽出了這個文件：

如果你打開這個文件，可以看見你修訂BUG的代碼也合并進去，你需要的是繼續(xù)在當前MyProduct上完成編譯和測試，最后簽入即可。

這里僅僅是一個演示，分支與合并其實是一門蠻高深的學問，我這里就不細說，僅作為一個引子。

補丁

當我們已經(jīng)修訂BUG并測試通過后，必然已經(jīng)更新了TFS上的bin目錄，我們可以根據(jù)比對歷史版本，來知道到底修改了哪些組件。

在bin目錄上點擊右鍵，選擇“View History 查看歷史”，在出現(xiàn)的歷史列表中，選擇兩個版本，然后點擊“Compare Folders 比較目錄”。最后出現(xiàn)這個清單：

這是手工操作的方法，我是不會這樣干的，我還是使用“項目工具”，首先看看目錄結(jié)構(gòu)：

你看見多了一個hotfixs目錄，下面的目錄名，其01是產(chǎn)品單元的編號，而119就是在TFS上的“Changeset 變更集”編號，“項目工具”總是檢測最后一個補丁的編號，并與最新的編號比較，就跟你上圖中手工處理一樣，獲取到清單后，工具就下載這些文件到一個臨時目錄，并使用安裝包制作工具創(chuàng)建一個補丁安裝程序。

可能你會說，并不是把最新的dll復(fù)制到客戶就能修正某個bug的，可能還需要修復(fù)數(shù)據(jù)庫的表結(jié)構(gòu)，甚至修復(fù)數(shù)據(jù)。是的，你說的沒有錯，但這個流程我們不會把他設(shè)計到補丁工具上，而是

這些最新的組件其包含這些功能，這樣補丁的流程就簡單很多。

如果你的某個版本時間跨度很長，很可能積累了很多的補丁，要知道這些補丁是向前依賴的，不能說單獨安裝一個補丁。我建議你的產(chǎn)品設(shè)計一個在線更新的功能，這樣就不會那么痛苦了。另外一個常見的實踐是制作SP1這樣的較大補丁包，他實際上就是把一堆的補丁合并成一個大補丁，方便新客戶的安裝。

有幾點要切記，切記：

• 補丁盡量只包含BUG的修訂，不要包含新功能；
• 給新客戶的安裝包，是原版+SP的形式，而不是直接一個最新版本。

這些忠告直接關(guān)系你的管理成本，如果你要問我為什么？怎么說呢，好復(fù)雜，你看Windows都是這么干的，O(∩_∩)O哈哈~算是解釋嗎。

中版分支

我知道，你在看到上面的第一點忠告時已經(jīng)暴跳起來，

天啊，客戶怎么可能等上一兩年沒有一個新版本？

做，當然做，不過我們換一種方法來做。

讓我們設(shè)想一下，如果你將新特性放在MyProduct_1.0源代碼中，就會出現(xiàn)一個問題，新特性的開發(fā)畢竟需要一個較長的編碼和測試周期，當客戶想你反映一個BUG時，你雖然可以很快修訂這個BUG，但是你無法發(fā)布給客戶，因為你的組件包含了很多尚未測試完畢的新特性，這個非常糟糕。

我的方法是，創(chuàng)建一個特性包分支，參加下圖

在完成1.0的發(fā)版后，會產(chǎn)生分支，這個我們上面已經(jīng)講過，并且在修正1.0的BUG后合并到開發(fā)版中，形成1.0.1版本。

在完成1.0分支后我們就開展了2.0的大規(guī)模開發(fā)，但我們會優(yōu)先開發(fā)R1的功能，在完成R1的開發(fā)和測試后，即1.1.1后，我們再次產(chǎn)生MyProduct-1.0 R1的分支，因為這個版本還包含了R1不需要的一些代碼（開發(fā)版不可能完全遵照R1的要求開發(fā)，可能更進一步），所以我們需要花一些時間調(diào)整和測試。

在此期間，如果在正式版發(fā)現(xiàn)的BUG仍然需要合并到開發(fā)版，但是無需合并到R1版本，因為我們很快就已經(jīng)將就緒的R1合并到正式版，然后封存R1這個分支，這樣我們就僅維護兩個版本。在日后的開發(fā)中，如果再次修訂BUG，你應(yīng)該選擇合并對應(yīng)的變更集，這是因為正式版已經(jīng)包含很多的R1代碼，如果選擇全部合并，會把R1的代碼也合并過來，而此功能在開發(fā)版已經(jīng)包括了。

特性包

事實上，中版的分支方式我是不喜歡的，因為不管TFS的分支與合并功能再好，我們也還是需要維護多套源碼，一個BUG在多處修訂容易，每處都要測試就不輕松了，這都是“成本”。

我更喜歡“特性包”這樣的方式。特性包的案例你可以想象是Word這樣的軟件，當Word開發(fā)完畢后，二次開發(fā)商利用提供的VSTO開發(fā)新的特性，二次開發(fā)商并沒有修改Word的源代碼，他們的代碼也沒有重疊，什么地方出現(xiàn)BUG就在什么產(chǎn)品單元上修改即可?；剡^來看我們的中版開發(fā)，你可以認為這個二次開發(fā)商就是自己。

特性包的做法前提是你的產(chǎn)品具有較強的二次開發(fā)能力，當開發(fā)完畢1.0后，并不立即產(chǎn)生分支，所有的中版開發(fā)放在一個獨立的產(chǎn)品單元，注意這個產(chǎn)品單元并不是一個分支，更不是一份拷貝的副本，而是基于1.0 SDK的二次開發(fā)。

從上圖可以看出，所謂特性版本就是一個獨立的產(chǎn)品單元，各自維護自己的BUG。但是這樣做對基礎(chǔ)產(chǎn)品的要求就比較高，要能在不改動基礎(chǔ)產(chǎn)品的情況下，完成很多的增強特性。當然，人無完人，產(chǎn)品也是，通常遇到不能支撐的時候，我們還是適當?shù)男薷牡讓樱３旨嫒荨?/p>

開發(fā)2.0產(chǎn)品的方法是，首先從1.0產(chǎn)生分支出MyProduct_2.0，將各個特性版的二次開發(fā)代碼整合到這個分支，最終形成2.0版本。但這個時候顯然還是要維護2套版本，當發(fā)布3.0時，需要維護3套版本。

另外一種比較極端的做法是，開發(fā)2.0仍然看成已有產(chǎn)品單元的再次二次開發(fā)，3.0也是。這種方法對底層平臺的要求更高，即特性版也能支撐二次開發(fā)。為提高性能，可以在特性版或各個補丁包安裝完畢后，執(zhí)行自動整合任務(wù)，以便將分散的二次開發(fā)整合成一個產(chǎn)品，有點像編譯的過程。