最新更新：冒煙提測後的一輪、二輪測試階段，由開發在各自需求分支上打包提供給測試，目前根據專案會生成T型小組，由開發各自負責一個平臺的打包，團隊成員逐漸形成習慣，很少在合程式碼上出現問題。
git工作流
引言
工作流英文名稱叫做“workflow”，高效的工作流能像流水一樣讓這個工作體驗順暢且自然。對於一個團隊來說，如果沒有制定規範有效的工作流程，那麼必定會導致混亂與低效，甚至會影響到團隊整個凝聚力與戰鬥力，更有甚者，會直接導致人員的流失與任務延期。 在日常的程式碼開發中，我們不可避免的會使用到版本管理工具，目前最常用的程式碼版本管理便是git，制定一套規範有效的git工作流來規範我們的分支管理和工作流程是極其必要的，並且越早越好。
現有的廣泛使用的git工作流
現在已經存在很多廣泛使用的git工作流，最常見的是git flow、github flow、gitlab flow，下面是這些git工作流的對比。
|
git flow
|
github flow
|
gitlab flow
|
|
|
簡介
|
最早誕生、並得到廣泛採用的一種工作流程
|
是git flow的簡化版，專門配合“持續釋出”，是github使用的工作流程
|
是git flow與github flow的綜合
|
|
特點
|
1.存在兩個長期分支，主分支master和開發分支develop
2.存在三種短期分支，功能分支、補丁分支、預釋出分支
|
只有一個長期分支（master）
|
它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利，它是gitlab推薦的做法
|
|
優缺點
|
清晰可控、相對複雜
|
簡單，但通常一個主分支不夠用
|
清晰可控、簡單
|
git工作流制定的目標是為了提高團隊效能，對於無線前端團隊來說，現有廣泛使用的git工作流並不能完全適用在實際的需求開發場景中，所以需要根據自己團隊特性來定製一套規範且有效的git工作流，命名為git-mango。
git-mango
git-mango是根據需求驅動設計的一套git工作流，主要包含分支管理和git工作流程管理兩個部分。
團隊及專案特性
- 敏捷開發，航班制進行版本釋出
- 混合型開發，APP專案涉及到android、ios、rn、rn-web
- 分支整合Jenkins進行自動打包和rn-web構建
為了解決的問題
- 對於開發人員，提高程式碼管理的效率與安全性
- 對於測試人員，避免產生版本混亂和需要重複校驗的情況，降低測試成本
- 對於分支管理人員，利於管理分支與觀察分支，保證專案程式碼的穩定性與安全性
- 對於這個需求開發中的團隊，在專案週期中提供順暢的git工作流，自然無阻
分支管理
git-mango中的分支管理部分將所有的分支分為三類，分別為雙主分支、特性分支和HotFix分支。分支管理首要解決的問題便是對於目前所有的分支進行規範，規範各分支的職責、操作許可權及命名，如果職責和許可權都不確定的話必定導致使用混亂，程式碼版本的穩定性被破壞。
雙主分支
雙主分支包含釋出分支（master）和提測分支（sit），雙主分支是一直跟隨著專案週期的，並且任何時候線上程式碼倉庫中都會儲存這兩個分支。
釋出分支（master）用於存放對外發布的版本，在任何時候拿到的都是穩定的版本，不允許在該分支上開發程式碼，只允許提測分支（sit）和熱修復（hotfix）分支提交程式碼合併。釋出分支的名稱不允許重新命名，通常以master作為名稱。
提測分支（sit）是開發完成後的提測分支，當需求開發完成且冒煙測試通過後便可以提交程式碼到sit分支。在sit分支上，還整合了Jenkins自動打包和rn-web構建等其他測試可用的功能。提測分支的名稱也不允許重新命名，可以用sit命名。
特性分支
特性分支又叫做需求開發分支，作為需求開發使用的分支，在啟動新需求開發時都會從master拉出一個最新的需求開發分支，只存在於一個版本需求開發週期中，成功上線即刪除分支。特性分支的命名以dev_開頭，後面拼接具體的子需求名稱，例如dev_pay支付需求的開發分支，如果一個版本上線存在多個子需求，那麼便會對應子需求建立各自的特性分支(dev_1、dev_2、dev_3)
“冷凍分支” 當這個特性分支上的需求不能上線或者延期上線該怎麼處理呢？因為特性分支只存在於一個版本需求開發週期中，這時候，該需求的特性分支便會變為冷凍特性分支，用於程式碼貯存及專案程式碼監控。例如dev_pay支付需求出現延期，這個版本上不了了，那麼這個時候便會變為freeze_dev_pay,到下個版本上線時，再申請一起上線，這時候冷凍分支便會轉化為一個正常的特性分支dev_pay，努力再上線。
HotFix
線上出現bug怎麼辦？HotFix只包含熱修復分支，作為一個最不想看到的分支卻存在著很強的必要性，在我們緊急處理線上的問題的時候起到很大的作用。每個熱修復分支的生命週期都是極其短暫的，在問題出現的時候，產生於一個master最穩定的tag版本，在問題修復完成後便會合併到master快速上線，上線成功，hotfix也就結束了。熱修復分支的名稱以hotfix_v_開頭，例如一個v1.3的版本出現了線上問題，便會拉一個hotfix_v1.3的分支。
下面是所有的分支管理圖
git工作流程管理
版本工作流週期
git-mango是基於需求驅動設計，在整個版本工作流管理中，也是基於需求開發的一個整體流程來劃分git-mango的生命週期，分別為需求任務確定階段、專案開發階段、測試階段和版本釋出階段。
git-mango工作流程
1.需求任務確定階段 圈定上線大需求以及包含的所有子需求，需求確認將會避免具體開發過程中很多的麻煩。需求任務確定好之後，便從master的當前穩定版本分別拉對應的子需求分支，並分配給相應的開發人員。
2.專案開發階段 在專案開發階段，對應需求開發人員只在對應子需求分支上進行程式碼提交,不允許提交到任何其他分支，直到開發結束，由專案負責人對該子需求的完成情況判斷是否能夠提測。
如果不能提測的話，便繼續開發或者直接轉化成冷凍分支，下個版本再提測上線，如果基本能夠提測的話，由對應開發和測試進行進行冒煙提測。
冒煙測試通過的話，則該需求則進入測試階段將該dev_特性分支程式碼合併到sit分支，如果冒煙測試失敗的話，則打回繼續在原開發分支進行開發。
3.測試階段 測試階段發現bug，修復bug在各自的特性分支上進行，不允許在sit上直接修復問題，修復完成後，再合併到sit，提供問題驗證，這樣能保持特性分支一直保持最新狀態並且相對獨立，這種做法是為了規避某個需求在測試階段無法正常上線而影響到其他需求上線。當出現測試階段有需求實在不能上線的時候，將sit上程式碼直接回滾到提測前節點，然後把各自能上線的子需求特性分支再次合併到sit分支。
4.版本釋出階段 sit測試通過，則進行程式碼封版，合併程式碼到master釋出分支上，然後從master分支再打一個待上線包，為上線做最後檢驗，測試通過則正常上線，並打tag記錄當前穩定版本如果測試失敗仍有bug的情況下，就需要在sit上進行問題修復，再合併到master，時刻保持sit分支與master分支的同步，無需後期再進行同步，防止漏同步的情況出現。
熱修復處理場景 熱修復的原則是最快解決問題，最快提交上線。當V1.2線上版本出現線上問題時，立馬從master上的V1.2tag拉一個hotfix_v1.2的熱修復分支進行問題修復，修復完成在本分支提交測試，測試通過則合併到master分支上，無論是否有其他需求在開發，都強制要求將master同步到sit分支。
git-mango工作流總圖
如何在團隊中使用git-mango流程
- 介紹git-mango，團隊成員瞭解後覺得OK再按流程走。
- 實踐中使用，在實踐中落地git-mango，有任何問題可以提出優化，在實踐中不斷地完善流程。
- 待流程已經形成了習慣並且確實提效時，便可以在團隊正式宣佈引入git-mango進行git工作流管理。
總結
流程的目標是去流程化，讓團隊成員潛移默化的養成好的的流程習慣。 流程的制定，最重要的是適合團隊，提高團隊效能。 流程的落地，要先投入實踐，再迭代優化後再正式投入到使用。