近期隨着團隊規模的擴大以及業務需求的逐漸增長，我花時間思考了團隊的代碼協作方式，過程中有些收穫跟大家分享一下。
首先推薦幾篇文章：
阮一峯的博客介紹了比較主流的集中Git工作流程，再加上這裏提到的SVN時代的單主幹模型，大家應該有個比較全面的認識了。
那麼這麼多的方式應該如何選擇呢？我目前的理解是：
單主幹模式
主幹開發，tag或分支發佈。這個應該不用考慮了，小項目，兩三個人應該還可以玩玩，否則可能應該可以忽略了。
Git Flow
適用於長週期的，基於版本發佈的項目。不太適合頻繁迭代的項目。
要點：長期維護master和development兩個分支。master保持絕對的純淨，更新只來自development的merge。development的更新來自其他所有功能branch的merge。在頻繁迭代的項目中，這兩個分支基本重合了，所以意義就不大了。
變更的開發過程：首先從development分支創建feature分支，進行相關開發，然後merge到development。之後這個feature分支就可以被刪除了。bugfix和預發佈也是同理
稍微繁瑣，一般通過腳本來簡化操作。
GitHub Flow
分支開發，主幹審查合併。流程簡單。其問題在於：master上的最新commit不等於正式版本：剛發佈的版本很快會被新提交更新。所以經常不得不新建production分支來跟蹤線上版本，以應對相關版本的bugfix等等。
GitHub flow 的好處在於非常簡單實用。開發人員需要注意的事項非常少，很容易形成習慣。當需要進行任何修改時，總是從 master
分支創建新分支。完成之後通過 pull request 和相關的代碼審查來合併回 master 分支。GitHub flow
要求項目有完善的自動化測試、持續集成和部署等相關的基礎設施。每個新分支都需要測試和部署，如果這些不能自動化進行，會增加開發人員的工作量，導致無法有效地實施該流程。這種分支實踐也要求團隊有代碼審查的相應流程。
GitLab Flow
上游爲先：Upstream First。嚴格設定分支優先級，只有上游採納的變更才能流到下游。
針對持續發佈的情況：
針對版本發佈的情況：
總結
這個總結真的很好。
還有這個網友的回答：
個人最終的補充：
- 個人所在的算法部門其實是整個系統的一個模塊，所以我傾向於使用GitHub+GitLab的方式
- 首先，針對相關算法需求，分支開發，主幹通過pull request合併。要有全面的測試和code review
- merge到主幹的節點必須是測試通過的可立即發佈的節點
- 如果發佈的版本需要持續跟蹤，或者不能做到立即發佈（代碼ready後到發佈上線中間時間較長，如app審覈，上線窗口限制，平臺方只能拉去分支的最新commit等等），那麼需要新建realese分支以進行跟蹤。因爲等待發布的同時，master仍然在不斷更新。