近期隨着團隊規模的擴大以及業務需求的逐漸增長,我花時間思考了團隊的代碼協作方式,過程中有些收穫跟大家分享一下。
首先推薦幾篇文章:
阮一峯的博客介紹了比較主流的集中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仍然在不斷更新。