【DevOps系列（一）】：規範程式碼管理之Git Flow_小余的自習室

🔥 Hi，我是小余。 本文已收錄到 GitHub · Androider-Planet 中。這裡有 Android 進階成長知識體系，關注公眾號 [小余的自習室] ，在成功的路上不迷路！

前言

相信大家對Git已經比我還熟悉了，所以本篇文章不會大篇幅的去講解Git中的各種命令，也沒必要，去官網或者一些部落格網站一搜一大堆，本文章主要來講解Git中一個比較標準化的流程 Git-Flow。

以前筆者使用Git的程式碼管理是這樣的：

gitflow前.png

可以看到版本非常混亂，對後期版本維護是非常不利的，分支一多很容易出現之前釋出過的版本找不到的情況，甚至引發一些bug，頭大的。。

作為一個小菜鳥，筆者去網上搜羅了一番，果然找到一個比較好的東西，Git-FLow。

什麼是Git-Flow呢？其實就是一個Git的標準控制流程或者說是一種約定,他可以解決你的程式碼控制混亂，發版混亂等眾多問題。。

下面我們來看下它的模型圖:

看不懂不要緊，下面我一一來分析。

1.分支情況

此圖中有5個分支型別：每個分支屬性是不一樣的

master分支：

這個不用介紹了吧，就是一個程式碼主線流程，注意哦，這個master分支只用來儲存已經發布的版本分支：

tag0.1，tag0.2表示使用tag來標記當前釋出的版本，這樣做的好處就是通過選中TAG就可以定位到某個釋出版本，相信還有一些程式設計師是用commit的message來標記版本的情況，可以改改啦。

develop分支：

就是開發用的主線分支，如果專案比較小，直接在這裡面開發是可以的，

但是對於一些需要多人協助非同步開發的情況，這個分支呢就會是一個開發的主線分支，一些工具類以及api文件的編寫可以在這上面commit，但是大部分的修改工作就要按feature進行分類了。

feature分支

假設我們有個開發專門做UI的，一個開發專門做NET的，一個開發專門做資料處理DATA的，為了專案順利進展就會在develop分支上開闢三個feature分支：UI分支，NET分支，DATA分支。

假如哪個分支做好了，且單元測試沒啥問題，就會將程式碼合併（使用merge或者rebase）到develop分支上，並隱藏當前feature分支。待三個分支都做好了，且都同步到develop分支上，develop分支在基礎測試沒問題後就會建立一個release分支。

release分支

release分支主要就是用來提供給客戶的釋出版本，因此對release版本還需要一個完整的測試，客戶驗收沒問題後，再將release分支程式碼同步到master分支上，使用tag標記版本資訊，並刪除當前release分支以及前面建立的feature分支。這樣整個需求通過細緻的分工完成了，且版本統一在master分支上管理。

hotfix分支

什麼是hotfix呢，言外之意就是熱修復的意思，這裡的熱修復和Android中的熱修復有點類似。

看圖中：

假設當前版本已經到了1.0了，但是有一天客戶說我機器出問題了，應用版本是0.1的，那麼此時你可能需要在0.1的版本做修復（當然在最新版本修復也可以，這裡說的是一定需要在舊版本做的修復），那麼就需要使用到hotfix分支了。

我們checkout到master分支的tag0.1處，建立一個hotfix分支，然後巴拉巴拉在上面一通操作之後呢，將修復好bug的hotfix分支合併到develop分支以及master分支，注意哦。因為develop分支是開發主線，假設使用hotfix修復了一個bug，不能僅僅同步到master，也要同步到develop分支，因為後期新增業務還是在develop分支上進行。

介紹完這幾個分支，再回頭去看這張圖是不是好像頓悟了呢？

好了，下面我來演示下如何在git中使用這套流程呢。

其實市面上大部分的git管理工具都集成了git-flow，如smartgit，fork等，下面小余使用fork來演示下git-flow的使用流程。

fork是一款免費的git管理軟體，而smartgit是一款收費軟體，用哪款大家自己選吧，功能都差不多。

2. git-flow實戰演練

1.首先我們在github上建立一個倉庫

2.使用fork工具將倉庫clone到本地

3.此時倉庫中只有main分支，點選fork選單欄的Repository->Git Flow->Initialize Git Flow..

可能你要說了，這不就是給我們建立了一個develop分支麼，額，確實是只建立了一個，別急，我們繼續後面的步驟。

4.假設此時我們有兩個分支任務，一個UI，一個NET。則點選fork選單的Repository->Git Flow->Start Feature

可以看到此時在feature下面建立了兩個分支feature-UI和feature-NET。

5.下面我們在兩個feature分支下面加幾個檔案或者改點東西。

首先在NET分支建立src以及doc資料夾，並在資料夾內部建立了兩個檔案。然後切換到UI分支，同樣建立src 以及doc資料夾，並在資料夾內部建立了兩個檔案。

修改後的支線圖如下：

可以看到UI以及NET兩個分支分別作了兩次修改，現在我們的UI完成了，需要合併到develop分支，如何進行呢？滑鼠右擊選擇Git Flow->Finish 'Feature/feature-ui' ，finish後feature-UI分支在branchs選單欄就消失了，檢視分支線圖：可知UI分支是被merge到main分支了。

用同樣的方式，對NET分支做finish操作，但是此時你會發現出現conflict了。

這是因為由於UI分支的合併，此時develop分支的README.md檔案被修改了，而在NET分支也對README.md檔案進行了更新，所以產生了衝突，這是一個很經典的問題，如何解決呢？

6.使用merge工具對衝突檔案進行合併：

最後衝突檔案選擇哪個分支的檔案就看UI和NET程式設計師溝通後的結果啦，

實際在開發過程中，對於都要使用的檔案可以在develop分支修改或者再使用一個feature分支修改大家都要用到的介面類，還有個辦法就是使用Cherry pick，關於什麼是Cherry pick自行百度看看吧。

另外如果是元件化開發的專案就不會有這個衝突了，因為元件化每個feature使用的檔案都是隔離的。

這裡假設選擇了NET分支的README.md檔案，然後對develop進行依次commit，最後finish掉feature-NET

分支。

最終分支圖如下：

可以看到當前只剩下了develop分支，feature-UI以及feature-NET已經被合併到develop中了。

6.到這步我們就需要開始準備釋出我們的版本啦，老操作，到Git Flow中點選start Release。

release的名字最好起的能讓人一眼就明白當前版本的資訊：release+版本號+日期。

7.建立release分支之後，前release就是要釋出的版本，如果測試下來發現有bug，則就在當前release版本上進行修改了，測試沒問題後就可以將交付產物提交給客戶了。此時develop分支依賴可以做自己的事情。和release分支是不衝突的。只是提交之後需要將release分支上修改的內容同步到develop分支，防止修復的bug未在develop分支中修復。