摘要：聊一聊Git中的工作流——分支策略。
本文分享自華為雲社區《Git工作流中常見的三種分支策略：GitFlow、GitHubFlow以及GitLabFlow》，原文作者：敏捷的小智。
前言
版本控制系統是指對軟件開發過程中程序代碼、配置文件、文檔等發生的變更進行管理的系統，它可以幫助團隊更好的溝通協作，從而更好的進行交付，常見的版本控制系統分為集中式版本控制系統（如SVN）和分布式版本控制系統（如Git）。
之前拜訪一家企業，企業內的開發團隊使用Git管理日常開發工作，在開發過程中遇到一個問題：分支策略使用很混亂——最初開發團隊從主干分支拉出一條特性分支，但新功能完成后，該特性分支沒有合入主干分支，而是作為下次開發的主干分支，重新拉出一條新的特性分支，導致主干分支一直形同虛設，團隊沒有一條穩定的代碼分支。
這個問題很大程度上源於團隊對分支策略的不了解，本文就簡單聊一聊Git中的工作流——分支策略。
常見的分支策略
上文中提到的團隊使用分支策略很混亂，這種分支策略也並不是主流的，使用主流的分支策略則會避免以上問題。
常見的分支策略有以下三種：GitFlow、GitHubFlow以及GitLabFlow。
Git Flow
GitFlow是這三種分支策略中最早出現的。
GitFlow通常包含五種類型的分支：Master分支、Develop分支、Feature分支、Release分支以及Hotfix分支。
- Master分支：主干分支，也是正式發布版本的分支，其包含可以部署到生產環境中的代碼，通常情況下只允許其他分支將代碼合入，不允許向Master分支直接提交代碼（對應生產環境）。
- Develop分支：開發分支，用來集成測試最新合入的開發成果，包含要發布到下一個Release的代碼（對應開發環境）。
- Feature分支：特性分支，通常從Develop分支拉出，每個新特性的開發對應一個特性分支，用於開發人員提交代碼並進行自測。自測完成后，會將Feature分支的代碼合並至Develop分支，進入下一個Release。
- Release分支：發布分支，發布新版本時，基於Develop分支創建，發布完成后，合並到Master和Develop分支（對應集成測試環境）。
- Hot fix分支：熱修復分支，生產環境發現新Bug時創建的臨時分支，問題驗證通過后，合並到Master和Develop分支。
通常開發過程中新特性的開發過程如下：
從Develop分支拉取一條Feature分支，開發團隊在Feature分支上進行新功能開發；開發完成后，將Feature分支合入到Develop分支，並進行開發環境的驗證；開發環境驗證完成，從Develop分支拉取一條Release分支，到測試環境進行SIT/UAT測試；測試無問題后，可將Develop分支合入Master分支，待發版時，直接將Master分支代碼部署到生產環境。
可參考下圖：
GitFlow的優點是每個分支都有明確的定義，嚴格按照GitFlow管理項目代碼的話，很難出現代碼混亂；其缺點是：如果特性分支過多的話很容易造成代碼沖突，從而提高了合入的成本；由於每次提交都涉及多個分支，所以GitFlow也太不適合提交頻率較高的項目。
使用華為雲 DevCloud 實現 Git Flow
1.創建分支
華為雲DevCloud的代碼托管功能支持端到端的GitFlow，我們在代碼倉庫中可新建分支，如圖，目前已有主要分支：Master分支和Develop分支，和兩個特性分支：Feature-Bill和Feature-Score分支。
2.為分支創建流水線
流水線功能需要在華為雲DevCloud的流水線功能中進行配置，基於“Feature-Bill”分支新建一條流水線。
在流水線中配置構建、部署任務，以便於對Feature-Bill分支代碼的構建、部署進行驗證（構建、部署等任務需要提前在對應模塊下創建）。
3.Feature提交代碼並驗證
Feature-Bill分支開發完成后，提交代碼即可觸發流水線進行驗證。
4.代碼合入 Develop 分支進行驗證
同理還需要為Develop分支創建一條流水線，當Feature-Bill分支通過merge命令合入到Develop分支之后，由於Develop分支的代碼發生了變化，也會觸發流水線進行驗證。
Develop分支驗證沒問題后，團隊可以拉取Release分支，創建並啟動Release分支的流水線進行測試環境驗證。若發現缺陷，可直接在Release分支進行修改、驗證。當測試環境驗證通過后，將代碼合入Master分支，創建並啟動Master流水線進行生產環境升級與驗證。
GitHubFlow
GitHubFlow看名字也知道和GitHub有關，它來源於GitHub團隊的工作實踐。當代碼托管在GitHub上時，則需要使用GitHubFlow。相比GitFlow而言，GitHubFlow沒有那么多分支。
GitHubFlow通常只有一個Master分支是固定的，而且GitHubFlow中的Master分支通常是受保護的，只有特定權限的人才可以向Master分支合入代碼。
在GitHubFlow中，新功能開發或修復Bug需要從Master分支拉取一個新分支，在這個新分支上進行代碼提交；功能開發完成，開發者創建Pull Request（簡稱PR），通知源倉庫開發者進行代碼修改review，確認無誤后，將由源倉庫開發人員將代碼合入Master分支。
很多人可能會問，提交代碼通常是commit或者push，拉取代碼才是pull，為什么GitHubFlow中提交代碼提出的是“Pull Request”。因為在GitHubFlow中，PR是通知其他人員到你的代碼庫去拉取代碼至本地，然后由他們進行最終的提交，所以用“pull”而非“push”。
GitHubFlow優點是相對於GitFlow來說比較簡單，其缺點是因為只有一條Master分支，萬一代碼合入后，由於某些因素Master分支不能立刻發布，就會導致最終發布的版本和計划不同。
GitLabFlow
GitLabFlow出現的最晚，GitLabFlow是開源工具GitLab推薦的做法。
GitLabFlow支持GitFlow的分支策略，也支持GitHubFlow的“Pull Request”（在GitLabFlow中被稱為“Merge Request”）。
相比於GitHubFlow，GitLabFlow增加了對預生產環境和生產環境的管理，即Master分支對應為開發環境的分支，預生產和生產環境由其他分支（如Pre-Production、Production）進行管理。在這種情況下，Master分支是Pre-Production分支的上游，Pre-Production是Production分支的上游；GitLabFlow規定代碼必須從上游向下游發展，即新功能或修復Bug時，特性分支的代碼測試無誤后，必須先合入Master分支，然后才能由Master分支向Pre-Production環境合入，最后由Pre-Production合入到Production。
GitLabFlow中的Merge Request是將一個分支合入到另一個分支的請求，通過Merge Request可以對比合入分支和被合入分支的差異，也可以做代碼的Review。
華為雲DevCloud也支持GitLabFlow的合並請求，以保護主干分支不收干擾。
1.設置保護分支
倉庫管理員在代碼托管的“設置”中，選擇“保護分支管理”，然后將Master（或Develop）分支設定為保護分支，普通開發者不可向Master分支提交代碼、也不允許合入代碼，只有倉庫管理員才可以向Master分支提交代碼或合入代碼。
2.創建合並請求
在代碼倉庫的“合並請求”中，創建一條合並請求，請求將Feature-Bill分支合入develop分支。
並指定評審人員和執行合入操作的人員。
3.Review代碼並通過合並請求
相關人員收到合並請求后，可以通過“文件變更”，比對文件前后的變化，確認無誤后，可執行合入操作，如果有沖突可線上或線下解決沖突。
除了執行合並操作，還可以對代碼進行評論打分，為Feature-Bill分支的合入提供建議。
總結
分支策略不同，研發效率也不同，沒有最好的分支策略，只有最適合團隊的分支策略，各分支策略的優缺點在上面已經列出，大家可以根據團隊情況，選擇合適的分支策略進行開發。