本文分享自華為雲社群《【雲小課】應用平台第44課 常用Git工作流推薦》，作者： 應用萬花筒. 。
1. Git工作流—動靜有法
簡單來說，工作流就是開發團隊預置的開發流程和解決問題時使用的協同約定。合理選擇工作流可以幫助團隊更好地進行項目管理與版本控制，是以在選擇工作流時，需要着重考慮團隊情況、規模、項目屬性與版本管理計劃。
2. 華為開發者常用的工作流
3. Git Flow—經典永不過時
在基于分支的代碼管理工作模式中，“Git Flow”在2010年被提出時，便被業界認可并廣泛應用，至今仍是經典，它充分發揮了Git分支工作模式的精髓。“Git Flow”工作模式并沒有用到複雜的指令和Git底層的結構，是為不同的分支配置設定一個很明确的角色，并定義各分支之間何時、如何進行互動。類似于經典的瀑布式項目管理模型，“Git Flow”相對龐大複雜，适用于中大型研發團隊，在處理複雜的研發項目時使用，項目越複雜、周期越長、需求越動蕩，參與者越會感受到這個工作模式的魅力與威力，前往感受經典的魅力！
圖1 Git Flow工作模式
提示：
在使用Git Flow工作模式時，業界普遍遵循的規則：
- 所有開發分支從develop分支拉取。
- 所有hotfix分支從master分支拉取。
- 所有在master分支上的送出都必須要有标簽，友善復原。
- 隻要有合并到master分支的操作，都需要和develop分支合并，保證同步。
- master分支和develop分支是主要分支，都是唯一的，其它派生分支每個類型可以同時存在多個。
4. GitHub Flow—探尋靈活之道
随着軟體行業競争日益激烈，能更快更早的為使用者提供新産品特性，俨然成為各企業渴望的核心競争力之一，靈活文化随之而生。
當項目經理們在學習、推進靈活改革時，開發者們也在尋求更簡潔的代碼托管模式，此時“GitHub Flow”進入了開發者的視線，它上手簡單，卻非常适配靈活開發環境，在中小型研發項目中，用“GitHub Flow”剛剛好。
它通常有一個主分支master，随時保持可部署狀态，每個新特性或新特性集單獨拉一條特性分支，例如feature_1/2/3...，在開發完成後直接在特性分支上進行測試，測試通過的特性分支經過分支合并評審（Merge Request，簡稱MR）後合并回 master 分支，此模式可以保證 master 分支随時都是可部署狀态。
可見，“GitHub Flow”是以DevOps持續傳遞為中心的工作模式，使用“GitHub Flow”的團隊在實際開發中甚至有一天之内會實施幾十次部署的，而支撐這一切的，就是這個足夠簡潔的工作模式以及華為DevCloud的CodeHub服務、自動化流水線服務。
圖2 GitHub Flow工作模式
提示：
在使用GitHub Flow工作模式時，業界普遍遵循的規則：
- 讓master分支總是保持可以部署的狀态。
- 進行新特性或新特性集開發時要從master分支建立新的分支，新分支名稱要具有描述性。
- 新特性分支的Commit一般在本地倉庫進行，當需要合并回master分支時，推送到遠端倉。
- 新特性分支合并回master分支前需要進行測試、評審與充分的交流，要確定合并後的master分支可用且經測試。
- 與master分支合并後，即可立即部署，使線上版本符合預期。
5. Trunk Based—歸本固源
Git提供了分支這一開發政策後，各種基于分支的代碼管理政策就如同雨後春筍般，紛紛被創造出來以應對各樣的研發場景，如前文介紹到的适用于大型項目的Git Flow、适用于靈活開發的GitHub Flow。
那麼如果我是個人開發者，亦或者我們是兩三人的小微團隊，有沒有适合我的Git工作模式呢？
當然有，它叫“Trunk Based”，與GitHub-Flow相同，它隻有一條長期分支，叫做Trunk或者master即為主幹，開發人員之間通過約定直接向被指定為主幹的分支送出代碼。“Trunk Based”是一種極簡的開發模式，它主張一切開發活動都直接在主幹分支完成，徹底根除了分支合并沖突的煩惱，并且項目中不會再有那些“你也說不上是幹嘛的”分支存在了。是以在個人項目中，這該是最主流的開發模式了。
可以說“Trunk Based”回歸了版本控制工具最本源的功能，很好了解也很好上手，對于項目的新進成員，導師不再需要教育訓練複雜的分支定義，隻需要告訴新來的“寫好的代碼記得Commit一下”。
當“Trunk Based”模式中項目需要釋出版本時，可以單獨拉出一條release分支，也可以直接在主幹上釋出。
沒有了分支的代碼隔離，測試和解決沖突都變得簡單，同時也鼓勵了項目成員進行更加頻繁的代碼內建和互動。
圖3 Trunk Based工作模式
提示：