關於分支or主幹開發模式的思考

大家坐下來討論各種開發模式。

A說：我們組同時開發的feature很多，所以必須要多分支，保證各個feature之間相互不影響，能方便地開發測試交付。
B說：我不想用多分支，要不然到合併的時候就頭疼了。
C說：或者我們可以用單分支單主幹，分支上開發，主幹上測試和交付，這樣保持測試時候的穩定性，合併的代價比較少。
A說：這樣還是有衝突的，如果一個feature合併到主幹在交付前測試時，其他feature想緊急上線，或者其他線上bug需要緊急修復怎麼辦？
D說：其實更好的模式應該是主幹開發，等到要release的時候拉一個releasebranch，在releasebranch上修復測試時候發現的bug，release branch只要足夠小（2-3天），就能避免衝突和緊急事件了。

我聽著聽著覺得很神奇，其實每一種開發模式都有利弊，甚至你根本無法判斷在特定情況下哪種開發模式更好了。 好吧，那不如跳出來，我們不要考慮開發模式了。你只要從比較好的幾種方法中挑出一種就可以了。 其實在開發模式後面，更重要的是開發的意識。
比如，如果是持續整合的話，如果你能夠保證ci的程式碼不影響整個系統的現有功能，那麼無論這個程式碼是完整還是不完整的，都可以釋出，這樣，我們壓根兒不需要討論是主幹上開發還是分支上開發，單分支上開發還是多分支上開發，它們不再是一個問題。
再比如，及時ci，你如果想知道整個團隊的動向，或者說，是程式碼的動向，那麼永遠不要一直在本地默默寫程式碼，否則很久以後，你會發現你離大部隊好遠追也追不上了（當然可以追上，只要你跑得氣喘吁吁狼狽不堪）。總是在ci程式碼，人家知道你在幹嘛，你也知道部隊在哪兒。同時，千萬不要忘了上面那個比如，否則系統不work了你就麻煩了。