git-使用規範

參考文檔

Angular.js commit messgae:
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits
Git - Book:
https://git-scm.com/book/zh/v1
A successful Git branching model » nvie.com
https://nvie.com/posts/a-successful-git-branching-model/
Git 開發流程:
https://gist.github.com/yesmeck/4245406

Git規範

分支管理

  1. 代碼提交在應該提交的分支
  2. 隨時可以切換到線上穩定版本代碼
  3. 多個版本的開發工作同時進行

提交記錄的可讀性

  1. 準確的提交描述,具備可檢索性
  2. 合理的提交範圍,避免一個功能就一筆提交
  3. 分支間的合併保有提交歷史,且合併後結果清晰明瞭
  4. 避免出現過多的分叉

團隊協作

  1. 明確每個分支的功用,做到對應的分支執行對應的操作
  2. 合理的提交,每次提交有明確的改動範圍和規範的提交信息
  3. 使用 Git 管理版本迭代、緊急線上 bug fix、功能開發等任務

分支說明與操作

分支管理規範:鏈接:https://nvie.com/posts/a-successful-git-branching-model/
在這裏插入圖片描述
Git-Flow 的經典流程圖

master 分支

  1. 主分支,永遠處於穩定狀態,對應當前線上版本
  2. 以 tag 標記一個版本,因此在 master 分支上看到的每一個 tag 都應該對應一個線上版本
  3. 不允許在該分支直接提交代碼

develop 分支

  1. 開發分支,包含了項目最新的功能和代碼,所有開發都依賴 develop 分支進行
  2. 小的改動可以直接在 develop 分支進行,改動較多時切出新的 feature 分支進行
    注: 更好的做法是 develop 分支作爲開發的主分支,也不允許直接提交代碼。小改動也應該以 feature 分支提 merge request 合併,目的是保證每個改動都經過了強制代碼 review,降低代碼風險

feature 分支

  1. 功能分支,開發新功能的分支
  2. 開發新的功能或者改動較大的調整,從 develop 分支切換出 feature 分支,分支名稱爲 feature/xxx
  3. 開發完成後合併回 develop 分支並且刪除該 feature/xxx 分支

release 分支

  1. 發佈分支,新功能合併到 develop 分支,準備發佈新版本時使用的分支
  2. 當 develop 分支完成功能合併和部分 bug fix,準備發佈新版本時,切出一個 release 分支,來做發佈前的準備,分支名約定爲release/xxx
  3. 發佈之前發現的 bug 就直接在這個分支上修復,確定準備發版本就合併到 master 分支,完成發佈,同時合併到 develop 分支

hotfix 分支

  1. 緊急修復線上 bug 分支
  2. 當線上版本出現 bug 時,從 master 分支切出一個 hotfix/xxx 分支,完成 bug 修復,然後將 hotfix/xxx合併到 master 和 develop 分支(如果此時存在 release 分支,則應該合併到 release 分支),合併完成後刪除該 hotfix/xxx 分支

以上就是在項目中應該出現的分支以及每個分支功能的說明。 其中穩定長期存在的分支只有 master 和 develop 分支,別的分支在完成對應的使命之後都會合併到這兩個分支然後被刪除。簡單總結如下:

  • master 分支: 線上穩定版本分支
  • develop 分支: 開發分支,衍生出 feature 分支和 release 分支
  • release 分支: 發佈分支,準備待發布版本的分支,存在多個,版本發佈之後刪除
  • feature 分支: 功能分支,完成特定功能開發的分支,存在多個,功能合併之後刪除
  • hotfix 分支: 緊急熱修復分支,存在多個,緊急版本發佈之後刪除

分支間操作注意事項

在團隊開發過程中,避免不了和其他人一起協作,同時也會遇到合併分支等一些操作,這裏提交 2 個個人覺得比較好的分支操作規範,這裏提交 2 個個人覺得比較好的分支操作規範。

同一分支 git pull 使用 rebase

下面這張圖展示了默認的 git pull 和 git pull --rebase 的結果差異,使用 git pull --rebase 目的是修整提交線圖,使其形成一條直線。
在這裏插入圖片描述
默認的 git pull 行爲是 merge,可以進行如下設置修改默認的 git pull 行爲:

#爲某個分支單獨設置,這裏是設置 dev 分支
git config branch.dev.rebase true
#全局設置,所有的分支 git pull 均使用 --rebase
git config --global pull.rebase true
git config --global branch.autoSetupRebase always

這裏需要說明一下,在我看來使用 git pull --rebase 操作是比較好的,能夠得到一條很清晰的提交直線圖,方便查看提交記錄和 code review,但是由於 rebase 會改變提交歷史,也存在一些不好的影響。

分支合併使用 --no-ff

  # 例如當前在 develop 分支,需要合併 feature/xxx 分支
  git merge --no-ff feature/xxx

在解釋這個命令之前,先解釋下 Git 中的 fast-forward: 舉例來說,開發一直在 develop 分支進行,此時有個新功能需要開發,新建一個 feature/a 分支,並在其上進行一系列開發和提交。當完成功能開發時,此時回到 develop 分支,此時 develop 分支在創建 feature/a 分支之後沒有產生任何的 commit,那麼此時的合併就叫做 fast-forward。
fast-forward 合併的結果如下圖所示,這種 merge 的結果就是一條直線了,無法明確看到切出一個新的 feature 分支,並完成了一個新的功能開發,因此此時比較推薦使用 git merge --no-ff,得到的結果就很明確知道,新的一系列提交是完成了一個新的功能,如果需要對這個功能進行 code review,那麼只需要檢視叉的那條線上的提交即可
在這裏插入圖片描述

項目分支操作流程示例

這部分內容結合日常項目的開發流程,涉及到開發新功能、分支合併、發佈新版本以及發佈緊急修復版本等操作,展示常用的命令和操作。

  1. 切到 develop 分支,更新 develop 最新代碼
git checkout develop
git pull --rebase
  1. 新建 feature 分支,開發新功能
git checkout -b feature/xxx
...
git add <files>
git commit -m "feat(xxx): commit a"
git commit -m "feat(xxx): commit b"
#其他提交
...

如果此時 develop 分支有一筆提交,影響到你的 feature 開發,可以 rebase develop 分支,前提是 該 feature 分支只有你自己一個在開發,如果多人都在該分支,需要進行協調:

# 切換到 develop 分支並更新 develop 分支代碼
git checkout develop
git pull --rebase

# 切回 feature 分支
git checkout feature/xxx
git rebase develop

# 如果需要提交到遠端,且之前已經提交到遠端,此時需要強推(強推需慎重!)
git push --force
上述場景也可以通過 git cherry-pick 來實現,有興趣的可以去了解一下這個指令。
  1. 完成 feature 分支,合併到 develop 分支
    #切到 develop 分支,更新下代碼
git check develop
git pull --rebase

#合併 feature 分支
git merge feature/xxx --no-ff

#刪除 feature 分支
git branch -d feature/xxx

#推到遠端
git push origin develop
  1. 當某個版本所有的 feature 分支均合併到 develop 分支,就可以切出 release 分支,準備發佈新版本,提交測試並進行 bug fix
#當前在 develop 分支
git checkout -b release/xxx

#在 release/xxx 分支進行 bug fix
git commit -m "fix(xxx): xxxxx"
...
  1. 所有 bug 修復完成,準備發佈新版本
#master 分支合併 release 分支並添加 tag
git checkout master
git merge --no-ff release/xxx --no-ff
#添加版本標記,這裏可以使用版本發佈日期或者具體的版本號
git tag 1.0.0

#develop 分支合併 release 分支
git checkout develop
git merge --no-ff release/xxx

#刪除 release 分支
git branch -d release/xxx
  1. 至此,一個新版本發佈完成。
  2. 線上出現 bug,需要緊急發佈修復版本
#當前在 master 分支
git checkout master

#切出 hotfix 分支
git checkout -b hotfix/xxx

... 進行 bug fix 提交

#master 分支合併 hotfix 分支並添加 tag(緊急版本)
git checkout master
git merge --no-ff hotfix/xxx --no-ff
#添加版本標記,這裏可以使用版本發佈日期或者具體的版本號
git tag 1.0.1

#develop 分支合併 hotfix 分支(如果此時存在 release 分支的話,應當合併到 release 分支)
git checkout develop
git merge --no-ff hotfix/xxx

#刪除 hotfix 分支
git branch -d hotfix/xxx
至此,緊急版本發佈完成。

提交信息規範

提交信息規範部分參考 Angular.js commit messgae
git commit 格式 如下:

<type>(<scope>): <subject>

各個部分的說明如下:

  1. type 類型,提交的類別
    1) feat: 新功能
    2) fix: 修復 bug
    3) docs: 文檔變動
    4) style: 格式調整,對代碼實際運行沒有改動,例如添加空行、格式化等
    5) refactor: bug 修復和添加新功能之外的代碼改動
    6) perf: 提升性能的改動
    7) test: 添加或修正測試代碼
    8) chore: 構建過程或輔助工具和庫(如文檔生成)的更改
  2. scope 修改範圍
    主要是這次修改涉及到的部分,簡單概括,例如 login、train-order
  3. subject 修改的描述
    具體的修改描述信息
  4. 範例
feat(detail): 詳情頁修改樣式
fix(login): 登錄頁面錯誤處理
test(list): 列表頁添加測試代碼

這裏對提交規範加幾點說明:

  • type + scope 能夠控制每筆提交改動的文件儘可能少且集中,避免一次很多文件改動或者多個改動合成一筆。
  • subject 對於大部分國內項目而已,如果團隊整體英文不是較高水平,比較推薦使用中文,方便閱讀和檢索。
  • 避免重複的提交信息,如果發現上一筆提交沒改完整,可以使用 git commit --amend 指令追加改動,儘量避免重複的提交信息。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章