【DevOps系列(一)】:規範程式碼管理之Git Flow

語言: CN / TW / HK

🔥 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分支中修復
  • 8.在成功交付給客戶以後,呼叫Git Flow的finish release刪除當前release版本,併合併到主分支main上

最後的分支圖如下:

可以看到這個支線圖就很清晰啦,主線main上只有一個1.0的釋出版本,且使用release-1.0這個Tag可以輕鬆定位當前版本所在位置。

hotfix如何使用

假設此時我釋出了兩個版本1.0和2.0。客戶說在1.0版本上出現了問題,那如何進行修復呢?

首先我們切換到main分支,然後checkout到1.0版本的tag,右擊Git Flow->Start Hotfix.

切換到hotfix-net分支後,我們給hotfix中改寫內容,然後commit,最後使用finish hotfix看看。

修改點:README.md增加內容:

時間/日期:17:44/2023-01-10 改動點: 1.測試hotfix-net

最後分支圖:

可以看到,分支圖在hotfix後,main主線上出現了第三個hotfix-net的tag,且最後的更改內容也成功移植到了main主線上,develop也同步了該TAG,說明此時的hotfix成功了。

小余在測試hotfix注意到:雖然我們checkout到出現問題的1.0版本,但是實際建立的hotfix是在2.0版本為基礎版本的,這個可能也是為了最新版本可以修復bug吧。

總結

本篇文章主要講解了關於Git-Flow在我們工作的使用方式,GitFlow更多的應該是一種約定而不是工具

當然如果你只是一個小的專案,遵守一些簡單的規則約定也就可以了,不一定要使用到Git_flow,對於一些稍微大點的專案可以考慮。畢竟學習成本也並不高。

好了,我是小余,歡迎點贊關注,我們下期見。

自我介紹.png 參考

https://nvie.com/posts/a-successful-git-branching-model/