最近跟一位朋友討論這個合併分支，落實到他舉例的項目上，我覺得應該記錄下來。因爲很多公司依舊這麼“合併分支”
先說說這位朋友的情況：
老規矩，上個圖，簡單的最有效。
朋友的做法是這樣的，trunk上做新功能，做出來以後，先做該部分的測試，測試好了以後，把該功能merge到branch A, branch A再給A客戶使用。
而branch B給另外一個B客戶使用，branch C給C客戶使用。
到這一切聽起來OK，但是問題在哪呢？把新feature merge到branch，這個做法，會導致很多人工的操作到裏面，就算在trunk上通過了測試，也不能保證merge到branch A上的時候沒有引入新問題。既然A,B,C客戶的代碼源都是trunk,那麼trunk上的代碼與branch上代碼的區別會越來越大，代碼merge時的重構需要的次數就越來越多，越來越久。
久而久之，工作量就大的一兩個人無法承擔。同時，測試的工作量，因爲merge的原因，無法保證測試的結果的正確性。我想，對客戶使用上來說，也是不太好的質量體驗。
那麼，問題來了，如果換做是我，如何做呢？
1.取消從trunk到branch的merge,改成每隔一定時間/功能數拉一次branch。新branch拉出來以後，對應的老branch廢棄。
2.做新feature加入開關機制，從而可以控制不同客戶的功能給不同客戶使用。
3.嚴格執行trunk只做新feature,branch用來查bug的制度，減少測試負擔。
4.trunk上只做新feature部分的UT/MT，branch上做整體測試。
按照以上的要求呢，上面的那個圖會變成 這樣：
那麼如何操作呢？
以客戶A那部分爲例，新功能a.1提交到trunk後，做UT/MT測試，通過後，拉分支branch A 0.1，該分支給測試人員做IT/ST，通過後發佈tag給客戶使用。客戶使用後肯定有新意見，新修改。那麼根據老規則 新修改會加入trunk，比如叫a.2，那麼又要拉branch 0.2做測試，又會出tag給客戶使用。如此重複，一直到客戶找不到問題，最終branch 1.0出山，最終1.0 打tag給客戶A使用，客戶絕對滿意。
那麼有人問，trunk上不只A客戶的需求啊，我B客戶的feature b只提了一半，A客戶的feature a.1做好了怎麼拉分支啊？
這裏，就需要解決方法的第2點了，所有的新feature，由一個配置文件來控制開關，feature b沒有開發完成之前，這個開關不打開，那麼及時拉出來a.1包含有B客戶的代碼也不用擔心，應爲該部分代碼並不起作用。該問題就完美解決了。順便說下，這個配置文件以後還能對不同客戶上面不同需求進行配置。
比如說某日你B客戶需要A客戶的某功能的時候，你可以瞬間收費了後，5分鐘就打開該功能。
那麼有人問，那麼“合併分支“乾的事情，這裏又如何解決的？
比如a.1新功能完成，拉出來的branch 0.1裏面就包含了a.1這個新功能。拉分支只需要svn copy這個命令。不需要人來看代碼如何merge，是否要重構，提交可能出現問題的代碼了。
至於測試那部分，由於UT/MT都可以由開發人員來做，真正做測試的那部分就到了branch上面。而每個branch都是增量增加功能的，測試部分可以做自動化的。那麼測試的effort就變小了。壓力也相對減少了。
看到這裏，看官們還要做“合併分支”麼？