最近跟一位朋友討論這個合併分支，落實到他舉例的專案上，我覺得應該記錄下來。因為很多公司依舊這麼「合併分支」
先說說這位朋友的情況：
老規矩，上個圖，簡單的最有效。
朋友的做法是這樣的，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的原因，無法保證測試的結果的正確性。我想，對客戶使用上來說，也是不太好的質量體驗。
那麼，問題來了，如果換做是我，如何做呢？
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就變小了。壓力也相對減少了。
看到這裡，看官們還要做「合併分支」麼？
你還在抱怨麼？
我們總是在抱怨。當我們的事業面臨失敗的時候，好像所有的矛盾的焦點都指向了周圍，而我們，似乎永遠是受害者。惡劣的工作環境，領導錯誤的決策，無能的同事，拖後腿的下屬 這一切都是我們向朋友，同事抱怨的資本，我們可以把一切壞的形容詞給我們曾經指導過我們的老師，領導，給和我們曾經一起奮鬥的同事們。給我們自己的...
若明天，你還在
若明天，你還在 春色濃郁，陽光晴好，我下車，剛好迎見你衝我微笑的臉 給，你的 我接過，望著定格在相片上記憶的畫面，不由得想起從前，想起我們之間，這五年。初中開學的第乙個晚自習，你在講台前做自我介紹，有條有理，有聲有色。每個新組成的班級都要在短時間內選出一名同學擔任班長，班主任見狀，指著從台上走下來的...
你還在兜圈嗎？
可能在我們每個人的人生路途中，一開始都是在兜圈，每次過完一年後只是單純地回到了起點。只有在領悟到這一點後，才知道要找到一條離開的路，然後不管是筆直地還是彎彎曲曲地向著目標前進，這樣的人生才是有意義的。也許每個人最大的不同就是領悟的早晚，可能有的人一開始就悟到了，比你早出發了幾年，十幾年。也可能有的人...