【DevOps系列(一)】:規範程式碼管理之Git Flow
🔥 Hi,我是小余。 本文已收錄到 GitHub · Androider-Planet 中。這裡有 Android 進階成長知識體系,關注公眾號 [小余的自習室] ,在成功的路上不迷路!
前言
相信大家對Git已經比我還熟悉了,所以本篇文章不會大篇幅的去講解Git中的各種命令,也沒必要,去官網或者一些部落格網站一搜一大堆,本文章主要來講解Git中一個比較標準化的流程 Git-Flow。
以前筆者使用Git的程式碼管理是這樣的:
可以看到版本非常混亂,對後期版本維護是非常不利的,分支一多很容易出現之前釋出過的版本找不到的情況,甚至引發一些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,對於一些稍微大點的專案可以考慮。畢竟學習成本也並不高。
好了,我是小余,歡迎點贊關注,我們下期見。
參考:
- 【重學C/C 系列(五)】:一文讀懂C 中的面向物件程式設計
- 不知道如何看原始碼?試試這幾種方式~
- 【DevOps系列(一)】:規範程式碼管理之Git Flow
- 【重學C/C 系列(四)】:函式體hack過程詳解
- 【重學C/C 系列(三)】:這一次徹底搞懂指標和引用
- "一文讀懂"系列:Android螢幕重新整理機制
- “一文讀懂”系列:無處不在的WMS
- 計算機組成原理系列(一):淺談計算機中的“補碼”
- 重學C 系列(一):從C到C
- “framework必會”系列:Android Input系統(一)事件讀取機制
- Android Framework知識整理:WindowManager體系(上)
- 基於Android T:包管理機制詳解(下)
- “framework必會”系列:Android Input系統(二)事件分發機制
- “一文讀懂”系列:AMS是如何動態管理程序的?