什么是主干開發？
主干開發往小了說，是版本管理的一種方式。往大了說，它是產品發布、研發團隊間協作、服務器測試環境管理等相關措施配合起來才能實現的一種交付方式，更確切的我們可以稱之為主干開發 - 分支發布的產品交付模式。
我們一般把Trunk（Master）稱之為主干，Branch稱之為分支，當然分支還可以sub-Branch，但是Trunk永遠只有一個。對應線上的版本，我們用稱之為發布分支的Release來管理。Release分支上永遠是穩定版本。
對於主干開發來說，代碼所經歷的過程是從開發人員的PC到Trunk到Branch最后到Release 的過程。根據代碼交付的路徑不同，另一種交付模式“分支開發”，分支開發的過程則是從開發人員的PC到Branch到Trunk最后到Release的過程。正是這中間兩步的差異，造就了兩個開發模式之間的天壤之別，而彼此的優缺點也大不相同。
從代碼的路徑我們可以看到多個開發人員的代碼的匯聚點在Trunk上，這就是主干開發第一個顯著的特點，即所有開發人員的代碼都是基於同一套代碼進行開發。開發人員每天都在這個主干上簽入簽出他們的代碼，不斷地集成，測試和修復，直到計划的發布的功能被實現的時候，再從這個版本打一個Tag，然后拉一個測試分支發布到系統測試環境。系統測試人員對測試分支進行系統測試。而同時開發人員則繼續在主干上開發新的功能。系統測試環境發現的缺陷，會在系統測試分支上被修復，修復后立刻同步到Trunk上。經過系統測試的版本接下來會發布到生產環境。而此時開發人員可能正在准備第二個版本的系統測試交付。
主干開發圖示
分支開發圖示
為什么主干開發將會成為主流？
主干開發模式極大消除了系統集成風險，讓原本痛苦的系統集成，在開發階段的時候就無時無刻的發生。這種模式把敏捷的持續集成實踐方法發揮到了極致。這就使得系統的潛在可交付產品（Potential Shippable Product）的成功率大大被提高了。與Scrum中的迭代潛在可交付產品略有不同的是，Scrum的迭代交付是在迭代內完整功能的交付，如果不能在本迭代做完的功能，則建議拆分地端到端更為細小或者放入下一個迭代來完成。直到可交付的功能可以滿足一定業務需要時，才進行系統測試和發布。當然在迭代過程中進行系統測試也不是壞事，只要有自動化或者人力保障（關於迭代內回歸測試對於剛轉型的scrum團隊來說，永遠是抹不掉的痛）。因此Scrum的發布周期和迭代長度往往是1：1或者1:N的關系。
回到主干開發的PSP。主干開發將要交付的版本並不包含所有完整，開發人員需要通過功能開關來屏蔽不希望用戶看到的功能。只有那些實現了完整業務的功能才會被展現在用戶面前。這樣做看上去很不“安全“，但是卻解決了功能不能拆分或不能組裝而無法完整業務發布、不能發布的問題。正因為這樣，主干開就發變得“准”時時可發布。它可選擇的發布窗口期可以不再是迭代的倍數，而是在迭代內也可以，甚至有團隊做到每天一發布。這種發布機制正式以快為重要特征的互聯網產品的所需要的。所以這種發布模式也必然是未來互聯網公司的主流模式。
主干開發與分支開發的優缺點
主干開發的具體形式是所有的開發人員在一個開一個主干上進行代碼的潛入簽出。其最大的好處在於在復雜環境中，讓風險提前被防范和消除。不過這種模式也有其局限性，特別是主干開發並不能很好地支持客制化產品的開發。對於需要客制化的產品，需要分為核心功能和定制功能。核心功能天生適合主干開發。而對於定制功能（最簡單的如：產品首頁Logo），則可通過配置的方式解決。簡單的說，我們希望的為每個定制產品增加一條配置信息，而不是一個分支產品。通過配置避免版本的分裂，這是最合理的分支方案。雖然隨着產品的發展，這類型的產品的定制化會越來越嚴重，這就迫使產品經理需要考慮是否需要這么多定制化，是否將某些定制化整合為核心功能，是否拋棄某些定制化的維護。這也是產品策略需要決定的方向之一。總的來說，主干開發其優點是：
- 發布頻率高 - 可以做到一周多次
- 團隊專注度高 - 團隊只關注當前版本的內容的開發和集成，沒有分支同步等困擾
- 系統集成風險低 - 在開發階段解決集成問題
- 統一的測試環境管理 -
其缺點是：
- 發布頻率受人數影響
- 依賴功能開關
- 不適合定制化產品開發
主干開發的前提條件和注意事項
很多團隊在嘗試主干開發，但是並不能很好地執行，因為在嘗試主干開發之前，需要認真思考一些東西，我們需要主干開放么？ 主干開發能幫我們解決現在的問題么？
同時也需要需考慮在做主干開發之前，是否滿足主干開發的其前提條件，以及在執行過程中時刻關注注意事項：
前提：
- 團隊理解主干開發的優缺點
- 團隊並掌握持續集成代碼管理步驟
- 需要移除多版本並行問題，否則無法基於一個主干版本進行開發
- 主產品，非分支產品開發
需要注意：
- 團隊力爭主干上的內容的穩定性，這樣才可使主干隨時可用
- 大部分開發人員在主干上進行開發，用分支方式解決實際開發過程中的一些問題
- 持續集成要不停的驗證主干和發布分支的穩定性和正確性。對於提交測試以后，要把對於主干問題，放到發布分支上進行驗證
- 生產上的內容必須是正常執行的，如果出現問題，先回滾到上一個主干發布的版本，然后按照按照特定的修復通道進行修復
總之，主干開發未來肯定是互聯網產品、單一產品的主流開發模式。從分支開發轉型到主干開發，可能讓你所在的團隊，組織的開發方式有很大的改變。但是這種改變一定是值得的。曾經有家公司在2個月不能交付的情況下，采用主干開發1個多月后實現了每星期兩次交付的頻率。這對以快為生命的互聯網企業來說，是重新獲得生機最有效方式。互聯網企業三大支柱是：業務的不斷創新、研發的快速交付、精確的運營反饋。少一個支點就不會走的很穩。而敏捷或主干開發是研發快速交付的有效方案。