git梳理三：工做流小結

版本控制工具只是提供了基礎能力，實際使用起來仍是有很大的靈活性。

一般來說，團隊協做的較大項目，總要有需求分支（特性分支）、主幹、發佈分支，它們之間應當是個什麼樣的關係？另外修復bug應該走什麼樣的流程，經過特定的分支發mr仍是直接提交到主幹？

結合實際軟件開發模式，造成了不一樣的實踐方案，咱們稱之爲，工做流。

這裏介紹幾種常見的工做流

• Git flow
• Github flow
• Gitlab flow

Git Flow

Git Flow是最先誕生的工做流，它有master和develop兩個長期分支。

master是最穩定的分支，只用來發布穩定版本。

develop分支則用來集成需求的開發。開發需求時從develop拉出feature分支，開發完後合回develop。

從develop拉出release分支，發佈預覽版之類的不穩定的小版本。若是有bug，在release分支上直接修復。等到版本穩定後，把release分支合回master和develop分支。

雖然release分支都是比較穩定後才合入master，但master上有時候仍會出現問題，這時候從master拉出hotfix分支進行修復，同時合入develop分支。

以上就是原始的Git Flow模型，在實際使用中仍是有一些變化的。首先，develop分支也是很容易出現需求無關的bug的，這時候會從develop分支拉出bugfix分支進行修復。

其次，release分支發現的bug，如今不少實踐中，每每是先修復到develop分支，再合入release分支。由於bug每每會影響進行中的需求開發，所以須要優先修復到develop。

能夠看到，Git Flow實際上是基於早期的軟件開發模式的：軟件存在穩定的大版本和不太穩定的預發佈小版本，把master用做最終穩定版使用。而現代的互聯網工程，更但願快速迭代，對這樣的穩定分支並沒有訴求。

Github flow

Github flow 是一個比較簡易的工做流，Github推薦的。

它只有一個長期分支，即master。須要開發需求或修bug時，從master拉出分支，改完後發起mr合回master。簡單粗暴。

它的顯著缺點是，假設了master的代碼是直接就能夠發佈的，對質量很高的小型項目或許是這樣，但對於一個大型項目來說，是很難作到的。不斷地有需求合入產生新的bug，master極可能是任什麼時候候都達不到發佈標準的。

固然，大型項目從master上再拉個分支用於發佈也是ok的。

Gitlab flow

Gitlab flow是gitlab推薦的工做流，在Github flow的基礎上補全了發佈這一塊的流程。

能夠說Gitlab flow是跟現代CI體系集成得最深刻的工做流。

對於版本發佈的項目，從master拉出發佈分支後，如需修復bug，應當拉bugfix分支而後發mr合入master，在經過cherry-pick合入發佈分支。使得發佈分支愈來愈穩定最終達到發佈標準並在合適時機發布。

對於一些持續發佈的項目，它推薦從Master拉出預發佈分支和發佈分支。注意，Gitlab認爲，在現代CI體系下，部署應當是基於分支或標籤的自動部署。即，代碼合入預發佈分支時，就應當自動觸發CI流程最終部署到預發佈環境；發佈分支同理直接對應生產環境。

國內CI用得這麼深的公司大概很少...不管如何，很是值得學習。

推薦閱讀GitLab Flow 的 11 條規則

gitlab flow官方文檔

結語

就我目前的經驗而言，github flow過於簡單，git flow的master在互聯網時代有點累贅，gitlab flow比較貼近我心目中的最佳實踐。

gitlab flow的持續集成類工做流，自動化程度很高，國內持續集成作到這個程度的公司大概很少，不過即便web項目，走它的版本發佈類工做流也是很nice的。

從新總結一下它的版本發佈類工做流：feature、bugfix經過mr合入master；發佈前從master拉出發佈分支；期間有bug先合入master再cherry-pick到發佈分支。

這套工做流應用其實很普遍，國外如facebook，國內如騰訊，都有大規模使用相似的工做流。