如何打造一個優雅的git工作流

語言: CN / TW / HK

在開發中,不論是一個團隊一起開發一個專案,還是自己獨立開發一個專案。都少不了要和git打交道。面對不同的開發場景,或許每個團隊都有自己的git工作流。這裡,我想分享一下我的團隊目前正在使用的基於gitlabgit工作流。一起交流一下。

規範化的git流程能降低我們的出錯概率,也不會經常遇到git問題,然後去搜一堆git高階用法。我們的這套git玩法兒,其實只要會基本的git操作就行了,然後規範化操作,基本不會遇到git問題,這樣大家就可以將時間用於業務上。最終,希望大家研究git的時候是在感興趣的時候,而不是遇到問題,緊急去尋找答案的時候

我們的這種git工作流玩兒法呢,主要是分為下面幾個分支:

  • master分支 最新的穩定程式碼
  • vx.x.x分支 版本分支,x.x.x是此次開發的版本號。
  • feat-xxx分支 特性(新的功能)分支
  • fix-xxx分支 修復分支

上面的這些分支呢,就是我們在開發中需要經常去建立並使用的分支。下面詳細說說每個分支代表的意思。

master分支代表的是最新的穩定版本的程式碼,一般是版本分支或者修復分支的程式碼上線後合併過來的。

feat-xxx分支表示的是為開發某個版本的某個新功能而建立的分支。

vx.x.x代表的是版本分支,這個是我們在每個版本開始前,以此次版本號為名從master建立的分支,比如版本號是 2.0.1,那麼版本分支則為 v2.0.1。然後等到該版本的各個新功能在feat-xxx開發完成並冒煙測試通過後,就到gitlab上提一個mr合併到該版本分支上。等到各個環境測試通過後,就將版本分支的程式碼合併到master上,然後就可以刪除本次的版本分支了。

fix-xxx表示的是修復分支,通常在處理線上問題時,建立一個以缺陷名稱命名的分支,在缺陷測試通過後,通過mr合併到master分支去

注意:這裡有個細節是,在特性分支上開發提交的commit資訊,一般認為是無用資訊,會在合併給版本分支的時候給合併到一個commit(由於我們是使用gitlab來合併,所以在發起mr請求時勾選squash選項就好了),而在提測後不論是修復測試過程中bug,或者是優化功能的commit則會全部保留,這個目的是一個警示,因為我希望最好的情況是提測即上線,雖然達到這個目標有難度,但是這些留下的commit資訊可以幫助我們覆盤

各個分支的作用如上面所描述的那樣,接著聊聊我們開發的一些經典場景該怎麼做:

第一個場景:正常開發迭代

我們以本次需要開發一個 1.0.0版本為例,這個其中有兩個功能模組,一個是需要新增一個按鈕,一個是需要新增一個表格

mermaid sequenceDiagram master->>v1.0.0: 從master切出 v1.0.0 master->>feat-add-button: 從master切出 feat-add-button master->>feat-add-form: 從master切出 feat-add-button feat-add-form->>feat-add-form: 開發完成 feat-add-button->>feat-add-button: 開發完成 feat-add-button->>v1.0.0: 在gitlab發起mr到v1.0.0,併合並所有commit feat-add-form->>v1.0.0: 在gitlab發起mr到v1.0.0,併合並所有commit v1.0.0->>v1.0.0: 提測 feat-add-button->>feat-add-button: 修復測試bug feat-add-button->>v1.0.0: 將修復的 commit cherry pick到 v1.0.0 v1.0.0->>master: 在gitlab上mr到master,並將合併資訊改成 v1.0.0

通過上面的時序圖,可以看到,我們以我們即將開始的版本命名了一個版本分支 v1.0.0,並且也根據這個版本下面的兩個功能建立了兩個特性分支 feat-add-buttonfeat-add-form,然後等功能開發完成後再通過gitlab發起mr(注意,這裡要把合併commit選項勾選上)合併到 v1.0.0,那麼 v1.0.0分支的程式碼就會從dev環境開始流轉,直到生產環境。這其中,如果有需要修復或者優化的地方,也是先修改特性分支,然後再cherry pick到版本分支上面。上線以後刪除版本分支以及下面的特性分支。

通過這個流程管理的程式碼版本非常清晰,這是擷取的master的一部分片段

image.png

在正常迭代流程還有個場景。那就是在開發過程中,pm突然過來說,因為某種不可抗力,有一個功能需要砍掉。這個時候,如果是程式碼還沒提測,亦或者是功能比較簡單,處理起來還不算麻煩。但如果是,你的功能和其他同事的程式碼已經在測試了,並且也已經修復了一些bug,commit都交叉在一起,特別是那種涉及修改檔案還多的需求,這個時候處理起來就很麻煩,不僅要看著別人的程式碼,還得警惕自己的程式碼別弄錯了。那這個時候,在我們流程裡就很簡單,直接刪除現有的版本分支就好了,再重新將需要上線的特性分支組合在一起就可以了。可以看到,版本分支是由特性分支組合起來的,也就是說,版本分支可以由不同的特性分支隨意組合。這樣處理起來就比較方便

第二個場景 線上bug修復

我們以線上需要修復一個按鈕的點選事件為例

mermaid sequenceDiagram master->>fix-button-click: 從master切出 fix-button-click fix-button-click->>fix-button-click: 修復問題並測試 fix-button-click->>master: 從gitlab發起mr合併到master

其實這裡的流程跟上面沒多大的區別,但是這裡需要注意的是,線上問題修復,一個bug一個commit,合併到master的時候不合並commit。而且需要將合併資訊修改為本次的版本號。比如本次則為 v1.0.1

第三個場景 多版本並行開發

這個場景跟正常迭代場景並沒啥區別,只是取決於你有多個版本,就建立對應的版本分支就可以了。每個版本分支按照正常迭代流程就可以了。

Q&A

Q:為什麼沒有使用dev、test等對應環境的分支,這樣也好實現push既部署

A:我們這個流程是放棄了使用這些固定的分支的。有幾個原因,

  1. 程式碼提測後從dev到test,甚至再到uat(預釋出)環境,如果在不同的環境都有程式碼的變動,那麼為了保持這些分支程式碼一致的話,就需要將程式碼同步到各個環境分支,這點兒有些費事兒。而版本分支不存在這個問題,版本分支只有一個,可以對應到各個環境。
  2. 方便多版本並行開發。版本分支可以建立多個,並行開發的時候比較方便部署到不同的測試環境。如果版本之間的模組關聯性不大,還可以並行測試。
  3. 語義化。版本分支可以通過分支名稱就知道目前有哪些分支正在開發中。

Q: master分支有變動怎麼處理

A: master分支有變動的話,及時的合併到自己的功能分支上,以防和其他成員程式碼有衝突

寫在最後

以上就是我的分享了,橘生淮南,適合我的未必適合大家,互相交流罷了

往期文章

怎麼自動化處理前後端對接過程?這是一個問題

如何實現一個虛擬事件?