Git 分支管理規範

程式設計師巨輪 發表於 2022-06-10
Git

Git-Bash 最佳指引手冊

每個人都應當遵循對於分支命名、標記和編碼的規範。每個組織都有自己的規範或者最佳實踐,並且很多建議都可以從網上免費獲取,而重要的是儘早選擇合適的規範並在團隊中遵循。

概述

  • DEV 環境 用於開發者除錯使用。

  • UAT 環境 使用者驗收測試環境,用於生產環境下的軟體測試者測試使用。

  • FAT 環境 功能驗收測試環境,用於測試環境下的軟體測試者測試使用。

  • PRO 環境 生產環境。

  • 專案域名為:http://www.jinmaocloud.com,相關環境的域名可這樣配置:

    DEV 環境:本地配置虛擬域名即可
    FAT 環境:http://fat.jinmaocloud.com
    UAT 環境:http://uat.jinmaocloud.com
    PRO 環境:http://www.jinmaocloud.com
    

分支

分支 名稱 環境 可訪問
master 主分支 PRO
release 預上線分支 UAT
hotfix 緊急修復分支 DEV
develop 測試分支 FAT
feature 需求開發分支 DEV

master 分支

  • master 為主分支,用於部署到正式環境(PRO),一般由 release 或 hotfix 分支合併,任何情況下不允許直接在 master 分支上修改程式碼。

release 分支

  • release 為預上線分支,用於部署到預上線環境(UAT),始終保持與 master 分支一致,一般由 develop 或 hotfix 分支合併,不建議直接在 release 分支上直接修改程式碼。

  • 如果在 release 分支測試出問題,需要回歸驗證 develop 分支看否存在此問題。

hotfix 分支

  • hotfix 為緊急修復分支,命名規則為 hotfix- 開頭。
    當線上出現緊急問題需要馬上修復時,需要基於 release 或 master 分支建立 hotfix 分支,修復完成後,再合併到 release 或 develop 分支,一旦修復上線,便將其刪除。

develop 分支

  • develop 為測試分支,用於部署到測試環境(FAT),始終保持最新完成以及 bug 修復後的程式碼,可根據需求大小程度確定是由 feature 分支合併,還是直接在上面開發。

一定是滿足測試的程式碼才能往上面合併或提交。

feature 分支

  • feature 為需求開發分支,命名規則為 feature- 開頭,一旦該需求上線,便將其刪除。

這麼說可能有點不容易理解,接下來舉幾個開發場景。

開發場景

新需求加入

有一個訂單管理的新需求需要開發,首先要建立一個 feature-order 分支,問題來了,該分支是基於哪個分支建立?
如果 存在 未測試完畢的需求,就基於 master 建立。
如果 不存在 未測試完畢的需求,就基於 develop 建立。

需求在 feature-order 分支開發完畢,準備提測時,要先確定 develop 不存在未測試完畢的需求,這時研發人員才能將將程式碼合併到 develop (測試環境)供測試人員測試。

  • 測試人員在 develop (測試環境) 測試通過後,研發人員再將程式碼釋出到 release (預上線環境)供測試人員測試。

  • 測試人員在 release (預上線環境)測試通過後,研發人員再將程式碼釋出到 master (正式環境)供測試人員測試。

  • 測試人員在 master (正式環境) 測試通過後,研發人員需要刪除 feature-order 分支。

普通迭代

有一個訂單管理的迭代需求,如果開發工時 < 1 天,直接在 develop 開發,如果開發工時 > 1 天,那就需要建立分支,在分支上開發。

開發後的提測上線流程 與 新需求加入的流程一致。

修復測試環境 Bug

在 develop 測試出現了 Bug,如果修復工時 < 2h,直接在 develop 修復,如果修復工時 > 2h,需要在分支上修復。

修復後的提測上線流程 與 新需求加入的流程一致。

修改預上線環境 Bug

在 release 測試出現了 Bug,首先要回歸下 develop 分支是否同樣存在這個問題。

如果存在,修復流程 與 修復測試環境 Bug 流程一致。

如果不存在,這種可能性比較少,大部分是資料相容問題,環境配置問題等。

修改正式環境 Bug

在 master 測試出現了 Bug,首先要回歸下 release 和 develop 分支是否同樣存在這個問題。

如果存在,修復流程 與 修復測試環境 Bug 流程一致。

如果不存在,這種可能性也比較少,大部分是資料相容問題,環境配置問題等。

緊急修復正式環境 Bug

需求在測試環節未測試出 Bug,上線執行一段時候後出現了 Bug,需要緊急修復的。
我個人理解緊急修復的意思是沒時間驗證測試環境了,但還是建議驗證下預上線環境。

  • 如果 release 分支存在未測試完畢的需求,就基於 master 建立 hotfix-xxx 分支,修復完畢後釋出到 master 驗證,驗證完畢後,將 master 程式碼合併到 release 和 develop 分支,同時刪掉 hotfix-xxx 分支。

  • 如果 release 分支不存在未測試完畢的需求,但 develop 分支存在未測試完畢的需求,就基於 release 建立 hotfix-xxx 分支,修復完畢後釋出到 release 驗證,後面流程與上線流程一致,驗證完畢後,將 master 程式碼合併到 develop 分支,同時刪掉 hotfix-xxx 分支。

  • 如果 release 和 develop 分支都不存在未測試完畢的需求, 就直接在 develop 分支上修復完畢後,釋出到 release 驗證,後面流程與上線流程一致。

檢出程式碼的姿勢

檢出遠端倉庫

可以檢出 origin/main 分支到本地,這是 GitHub 建立倉庫時預設的 主機名/分支名。使用 git branch -vv 檢視本地分支狀態

本地分支名為 main,關聯的遠端分支名為 origin/main(origin 是主機名,main 是分支名

檢出遠端分支

  • 一個專案需要新建很多遠端分支,以便於並行開發

同步遠端分支

檢出遠端分支

提交程式碼的姿勢

永遠不要在一個本地分支上,連續提交程式碼。在多人協作的情況下,這會導致每筆提交之間存在依賴關係,進而可能導致 merge 衝突、cherry-pick 合入冗餘程式碼。

  1. 暫存程式碼

    git stash save [-u] 'update readme.md'

    [-u] 表示引數可選,加 -u 會將本地新增檔案也暫存,不加則僅暫存本地修改部分。'update readme.md' 為描述,下面列出 git stash 支援的所有操作:

    • git stash list 顯示所有暫存記錄
    • git stash show [email protected]{0} 檢視指定的暫存記錄
    • git stash pop [email protected]{0} 彈出指定的暫存記錄
    • git stash drop [email protected]{0} 刪除指定的暫存記錄
    • git stash clear 清空暫存記錄
  2. 同步程式碼

    git pull --rebase

  3. 彈出暫存程式碼

    git stash pop [[email protected]{0}]

    [[email protected]{0}] 表示可選,不加預設彈出棧頂元素,也可以指定彈出哪一個暫存記錄。彈出結果如下:

  4. 新建本地分支

根據不同功能新建不同的本地分支,比如 feature_shopping,bugfix_tombstone 等等,假設我們現在需要實現一個購物功能,我們應該使用 git checkout -b feature_shopping 新建一個本地分支來實現這個需求:

  1. 提交程式碼

git commit -m "update README.md" 表示將修改提交到本地倉庫,此時還沒有推送到遠端倉庫。-m 後面的是修改描述,這是一種簡便寫法。

  1. 追加提交

commit 之後,本地又修改了一些檔案,此時需要使用 git commit --amend 追加提交:

  1. 回退提交

commit 之後,發現提交多了,把不需要提交的也提交了,此時需要回退,有兩種方式:

git reset [--soft] commit_id,軟回退,不會丟棄檔案修改記錄,--soft 不加也可以。
git reset --hard commit_id,硬回退,丟棄所有修改。一般僅在需要回退到指定節點驗證問題時使用。

檢視 commit_id:

  git log -1

-1 表示只檢視提交記錄裡的最後一條:

輸入 git reset 22d92a412e7ed6e72ee2107db891e7571d307c81,即可回退提交。然後重新 git add ...,git commit。

  1. 推送程式碼

commit 之後很多人就直接 git push 了,這是不對的,應當先同步程式碼。由於我們現在在新建的本地分支 feature_shopping 上,這個分支沒有關聯遠端分支,所以無法也不應該使用 git pull --rebase 來同步程式碼。正確的操作為:

git checkout master:切到本地主分支
git pull --rebase:同步程式碼
git checkout feature_shopping:切換到本地需求分支
git rebase master:將本地主分支程式碼,合入到本地需求分支(可能有衝突,按照 Git 的提示修復即可)
git push origin HEAD:refs/for/master:將本地需求分支的提交推送到遠端 master 分支