Git工作流

Gitflow模式

特點(diǎn)：使用發(fā)布分支、特性分支、bug 修復(fù)分支以及預(yù)發(fā)布分支。主要分支包括 master、develop、feature、release、hotfix。

由于Gitflow模式涉及到了很多不同的分支名稱，所以這里我打算用一系列的圖來和大家介紹下這些分支的概念。

master/feature/develop 分支

首先我們的master分支一定是最終發(fā)布上線使用的分支代碼，所有的需求開發(fā)，都需要通過master分支中去checkout出來，生成對(duì)應(yīng)的feature分支。

當(dāng)同一個(gè)項(xiàng)目涉及到多個(gè)分支改動(dòng)的時(shí)候，就難免會(huì)需要進(jìn)行分支合并后再發(fā)布到開發(fā)環(huán)境的情況發(fā)生。

這時(shí)候可以通過利用新增一條develop分支的做法，將同一個(gè)項(xiàng)目的多條feature分支進(jìn)行merge后，再發(fā)布到開發(fā)環(huán)境中。如下圖所示：

圖片

采用新增develop分支的模式可以解決開發(fā)環(huán)境多分支合并部署的問題了。那么release分支又是做什么的呢？

release 分支

開發(fā)環(huán)境一般主要是給開發(fā)調(diào)試程序時(shí)候使用的，而如果要從開發(fā)狀態(tài)轉(zhuǎn)變?yōu)闇y試狀態(tài)的話，需要的是一個(gè)能夠長期保障穩(wěn)定性和邏輯順暢性的代碼環(huán)境，這個(gè)時(shí)候建議可以通過新增一套release分支來進(jìn)行測試環(huán)境的代碼管理。如下圖所示：

圖片

從圖中可以看到，不同開發(fā)負(fù)責(zé)的feature分支，在進(jìn)行提測的時(shí)候都需要往相同的release分支進(jìn)行合并。

當(dāng)release分支上的代碼通過測試回歸之后，我們可以視作此時(shí)的release分支的代碼是屬于可合并到master的狀態(tài)。因此一般這個(gè)時(shí)候會(huì)將release分支的代碼分別合并到master和develop分支上，以此來保證準(zhǔn)確性。同時(shí)此時(shí)可以將master分支的代碼發(fā)布到預(yù)發(fā)環(huán)境進(jìn)行最后的回歸驗(yàn)證。

hotfix分支

其實(shí)hotfix分支在使用上可以說和feature分支基本一樣，它的定位是：對(duì)master分支上的bug進(jìn)行修復(fù)。hotfix分支也是需要從master分支中checkout出來，然后進(jìn)行修改，最后合并到develop/release分支上進(jìn)行回歸驗(yàn)證，最后并入到master分支進(jìn)行發(fā)布。在一定程度上，hotfix屬于feature分支的一種特殊類型。

圖片

git-flow模式的痛點(diǎn)

其實(shí)用久了git-flow模式后，你會(huì)很容易發(fā)現(xiàn)，這種模式對(duì)于分支的領(lǐng)域劃分是非常清晰的。例如develop分支專門用于開發(fā)，release分支專門用于測試，hotfix分支專門用于打補(bǔ)丁。

但是隨著迭代的增加，這些分支的管理是一件比較容易出錯(cuò)的事情。例如：手誤將feature分支合并到release分支。hotfix分支忘記合并到develop分支等等。release分支包含了太多feature分支代碼，其中部分feature分支延遲上線導(dǎo)致release分支代碼需要移除部分commit后再合并到master分支。

這是我認(rèn)為的git-flow模式的一大痛點(diǎn)。雖然它強(qiáng)調(diào)于對(duì)分支的標(biāo)準(zhǔn)化管理，但是實(shí)際落地在團(tuán)隊(duì)使用的時(shí)候，很多毛病都會(huì)體現(xiàn)出來。

Github flow模式

特點(diǎn)：Github flow 是Git flow的簡化版，專門配合"持續(xù)發(fā)布"。它是 Github.com 使用的工作流程。

步驟

1. 拉取最新的代碼：git pull origin master 
2. 創(chuàng)建新的功能分支：git checkout -b feature-branch master
3. 開發(fā)功能：在新創(chuàng)建的分支上進(jìn)行修改、提交和測試
4. 合并到master：git checkout master -> git merge feature-branch
5. 推送到中央存儲(chǔ)庫：git push origin master

圖片

這種模式比較適合于合作人數(shù)較少的場景中進(jìn)行快速開發(fā)和迭代。在實(shí)際使用中，團(tuán)隊(duì)leader只需要保障master分支的“干凈”即可。各個(gè)團(tuán)隊(duì)成員的特性分支代碼獨(dú)立。但是如果是涉及到需要多人合作對(duì)同一個(gè)項(xiàng)目進(jìn)行并行開發(fā)，需要多次進(jìn)行代碼合并的話，這種開發(fā)模式就很痛苦。

Gitlab flow 模式

采用Github flow模式雖然說很靈活，但是它有個(gè)強(qiáng)制的要求就是master分支的代碼一定要和生產(chǎn)環(huán)境的代碼對(duì)齊。

但是在一些特殊的應(yīng)用場景中，例如IOS開發(fā)（需要有審核時(shí)間），某些SAAS平臺(tái)的一些特殊功能開發(fā)，在那類場景中經(jīng)常是會(huì)出現(xiàn)代碼合并到master，但是需要延遲一段時(shí)間才發(fā)布到生產(chǎn)環(huán)境。

Gitlab flow模式就是在上述的Github flow模式中進(jìn)行的衍生，增加了一個(gè)所謂的pre-production分支，用于作為待發(fā)布狀態(tài)的環(huán)境分支，它的代碼合并流程如下所示：

圖片

處于pre-production分支的代碼是經(jīng)過驗(yàn)證可以合并到生產(chǎn)環(huán)境的代碼，而production分支的代碼則是生產(chǎn)正在運(yùn)行中的代碼。這個(gè)由pre-production到production分支的合并動(dòng)作，需要由CICD平臺(tái)自動(dòng)化來實(shí)現(xiàn)。

說實(shí)話，我在實(shí)際工作中主要還是用的Github flow模式，Gitlab flow模式個(gè)人接觸得并不多。

我的看法

早些年工作的時(shí)候，經(jīng)歷過一些多人合作修改同一個(gè)項(xiàng)目的開發(fā)工作。那會(huì)團(tuán)隊(duì)采用的是git flow的工作流，當(dāng)時(shí)總是會(huì)出現(xiàn)合并沖突，分支錯(cuò)亂，git命令使用錯(cuò)誤導(dǎo)致代碼丟失等問題。

但是隨著這些年微服務(wù)的普及，很多公司其實(shí)都已經(jīng)陸續(xù)意識(shí)到了大單體架構(gòu)的痛點(diǎn)，于是也按照領(lǐng)域劃分拆解為了多個(gè)微服務(wù)。

實(shí)際上，隨著微服務(wù)粒度在不斷降低，每個(gè)開發(fā)所負(fù)責(zé)的領(lǐng)域也開始進(jìn)行了劃分。如果服務(wù)劃分合理，其實(shí)一個(gè)項(xiàng)目基本上主需要一個(gè) 主程 （core  developer，有些公司習(xí)慣叫項(xiàng)目owner）去維護(hù)基本就OK了。如果是這種模式下進(jìn)行代碼開發(fā)的話，其實(shí)采用經(jīng)典的 github flow 或者 gitlab flow 模式進(jìn)行開發(fā)即可滿足。

我認(rèn)為，隨著日后的發(fā)展，業(yè)內(nèi)技術(shù)的走向一定是將事情由繁化簡。隨著企業(yè)內(nèi)部的CICD技術(shù)體系完善，git flow這種笨重的模式也會(huì)漸漸被摒棄，github flow/gitlab flow 這種靈活輕便的模式會(huì)越來越受人追崇。

對(duì)于git工作流模式來說，我認(rèn)為沒有絕對(duì)完美的方案，只能說結(jié)合當(dāng)前所遇到的業(yè)務(wù)場景來靈活制定，見招拆招。