爲無線前端團隊打造高效git工做流

最新更新：冒煙提測後的一輪、二輪測試階段，由開發在各自需求分支上打包提供給測試，目前根據項目會生成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構建

爲了解決的問題

1. 對於開發人員，提升代碼管理的效率與安全性
2. 對於測試人員，避免產生版本混亂和須要重複校驗的狀況，下降測試成本
3. 對於分支管理人員，利於管理分支與觀察分支，保證項目代碼的穩定性與安全性
4. 對於這個需求開發中的團隊，在項目週期中提供順暢的git工做流，天然無阻

分支管理

git-mango中的分支管理部分將全部的分支分爲三類，分別爲雙主分支、特性分支和HotFix分支。分支管理首要解決的問題即是對於目前全部的分支進行規範，規範各分支的職責、操做權限及命名，若是職責和權限都不肯定的話一定致使使用混亂，代碼版本的穩定性被破壞。

雙主分支

雙主分支包含發佈分支（master）和提測分支（sit），雙主分支是一直跟隨着項目週期的，而且任什麼時候候線上代碼倉庫中都會保存這兩個分支。

發佈分支（master）用於存放對外發布的版本，在任什麼時候候拿到的都是穩定的版本，不容許在該分支上開發代碼，只容許提測分支（sit）和熱修復（hotfix）分支提交代碼合併。發佈分支的名稱不容許重命名，一般以master做爲名稱。

提測分支（sit）是開發完成後的提測分支，當需求開發完成且冒煙測試經過後即可以提交代碼到sit分支。在sit分支上，還集成了Jenkins自動打包和rn-web構建等其餘測試可用的功能。提測分支的名稱也不容許重命名，能夠用sit命名。

特性分支

特性分支又叫作需求開發分支，做爲需求開發使用的分支，在啓動新需求開發時都會從master拉出一個最新的需求開發分支，只存在於一個版本需求開發週期中，成功上線即刪除分支。特性分支的命名以dev_開頭，後面拼接具體的子需求名稱，例如dev_pay支付需求的開發分支，若是一個版本上線存在多個子需求，那麼便會對應子需求創建各自的特性分支(dev_一、dev_二、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工做流管理。

總結

流程的目標是去流程化，讓團隊成員潛移默化的養成好的的流程習慣。 流程的制定，最重要的是適合團隊，提升團隊效能。 流程的落地，要先投入實踐，再迭代優化後再正式投入到使用。