Git Commit Patterns

From Git Commit Patterns : https://dev.to/jasonh33/git-commit-patterns-5dm7

Type: What are the types of commits

The type is responsible for telling us what change or iteration is being made, from the convention rules, we have the following types:

  • test: indicates any type of creation or alteration of test codes. Example: Creation of unit tests.

  • feat: indicates the development of a new feature for the project. Example: Adding a service, functionality, endpoint, etc.

  • refactor: used when there is a code refactoring that does not have any impact on the system logic/rules. Example: Code changes after a code review

  • style: used when there are code formatting and style changes that do not change the system in any way. Example: Change the style-guide, change the lint convention, fix indentations, remove white spaces, remove comments, etc…

  • fix: used when correcting errors that are generating bugs in the system. Example: Apply a handling for a function that is not behaving as expected and returning an error.

  • chore: indicates changes to the project that do not affect the system or test files. These are developmental changes. Example: Change rules for eslint, add prettier, add more file extensions to .gitignore

  • docs: used when there are changes in the project documentation. Example: add information in the API documentation, change the README, etc.

  • build: used to indicate changes that affect the project build process or external dependencies. Example: Gulp, add/remove npm dependencies, etc…

  • perf: indicates a change that improved system performance. Example: change ForEach to While, etc…

  • ci: used for changes in CI configuration files. Example: Circle, Travis, BrowserStack, etc…

  • revert: indicates the reversal of a previous commit.

Git Commit Guidelines

分支管理

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

記錄的可讀性

  • commit內容按照格式執行.
  • 正確設置user.name和user.email信息.

版本號(tag)

  • 版本號(tag)命名規則
  • 主版本號.次版本號.修訂號，如2.1.13
  • 對master標記tag意味著該tag能發佈到生產環境
  • 版本號僅標記於master分支，用於標識某個可發布/回滾的版本代碼
  • 僅項目管理員有權限對master進行合併和標記版本號

():

type

  • feat: 新功能
  • fix: 修復 bug
  • docs: 文檔變動
  • style: 單純的格式調整
  • refactor: bug 修復和添加新功能之外的代碼改動
  • perf: 提升性能的改動
  • test: 添加或修正測試代碼
  • chore: 構建過程或輔助工具和庫的更改

scope 修改範圍

  • 這次修改涉及到的部分簡單概括
  • login、train-order

subject 修改的描述

  • 具體的修改描述信息
  • provide issue id

Example:

  • feat(detail): 詳情頁修改樣式
  • fix(login): 登錄頁面錯誤處理
  • test(list): 列表頁添加測試代碼
  • feat(detail): 詳情頁修改樣式

Version

主版本號 (major) 當有重大升級改動. 當做了不兼容的 API 修改. 次版本號 (minor) 當做了向下兼容的功能性新增. 修訂號 (patch) 當做了向下兼容的問題修正.

lable:

  • alpha:內部測試版
  • beta:公開測試版
  • rc: 候選版本, 不再增加新功能.

Git Flow

  • master
    • git merge hotfix
    • git merge release/v1.0.0-rc.0
  • hotfix
    • git checkout -b hotfix/fix-timeout master
  • release
    • git checkout -b release/v1.0.0-rc.0 develop
  • develop
    • git checkout -b develop master
  • feature
    • git checkout -b feature/add-timeout develop
    • git checkout -b feature/issue-6379 develop

]git flow

master

使用規範:

  • master分支存放的是隨時可供在生產環境中部署的穩定版本代碼
  • 使用 tag 標記一個版本用於發布或回滾
  • master分支是保護分支，不可直接push到遠程倉master分支
  • 如當前版本出現異常, 可先使用 tag 配合 cicd 進行回滾.

不能直接push, 合併走 merge request 流程

develop

使用規範:

  • develop分支作為開發的主分支, 保存當前最新開發成果的分支
  • 由 develop 分支衍生出各個 feature 分支
  • 建議新功能和修復開發都在 feature 分支進行

建議鎖定 develop 分支, 禁止push提交代碼, 代碼合併走 merge request

feature

使用規範:

  • 分支的命名格式建議 feature/login or feature/issue-3677
  • 以功能為單位從 develop 拉一個 feature 分支
  • 每個 feature 分支顆粒要盡量小，以利於快速迭代和避免衝突
  • 當其中一個feature分支完成後，需合併回 develop 分支，另需刪除 feauter/xxx 分支
  • feature分支只與 develop 分支交互，不能與 master 分支直接交互

bugfix

使用規範:

  • 分支的命名格式建議 bugfix/fix-login or bugfix/issue-1314
  • 由 develop 分支衍生用來修復問題用的分支
  • bugfix 分支跟 develop 分支合併, 不能越界跟其他高分支交互

使用 feature 做解決問題的分支不是很合適 ?

release

使用規範:

  • 分支的命名格式建議 release/v1.0.0.rc.0 類似這種.
  • release主要用來為發布新版的測試、預發布、修復的分支.
  • release分支可以從develop分支上指定commit派生出.
  • release分支測試通過後，合併到master分支並且給master標記一個版本號.
  • 如在 release 分支發現 bug 可在 release 中修復，測試完成後合併到 develop 和 master 分支.
  • release分支一旦建立就將獨立，不可再從其他分支pull代碼.

如項目不大可省略該分支，避免繁瑣的 gitflow 過程 !!!

hotfix

使用規範:

  • 命名規則:hotfix/， 以本次發布的版本號為標識.
  • hotfix分支用來快速給已發布產品修復bug或微調功能.
  • 只能從master分支指定tag版本衍生出來.
  • 一旦完成修復bug，必須合併回master分支和develop分支.
  • master被合併後，應該被標記一個新的版本號.
  • hotfix分支一旦建立就將獨立，不可再從其他分支pull代碼.

reset vs revert

強烈建議

  • 在公共分支做 revert
    • revert 會刪除某提交的變更，然後產生新的提交，並不會真正刪除history.
  • 在自己分支做 reset .
    • soft: 回滾到某提交，但變更保留在工作區內，供開發者選擇
    • hard: 徹徹底底的回滾到某提交, 清空暫存區和工作區.

不要在公共分支做 reset 操作 !!!

fast-forward

從dev分支創建了feature分支，feature進行功能開發 並提交後， 在dev對feature分支進行合併， 如feature 提交期間dev無其他變更這時的合併就是 fast forward 模式.

git merge dev --no-ff -m "merge with no-ff"

rebase vs merge

建議

  • 下游分支更新上游分支內容的時候使用 rebase
  • 上游分支合併下游分支內容的時候使用 merge
  • 更新當前分支的內容時一定要使用 --rebase 參數

不建議在公共分支上使用rebase

merge 注重歷史紀錄

rebase 注重線性提交

合併多個commit記錄

  • merge squash
    • 在上游分支操作
    • git merg -squash
  • rebase squash
    • 在下游分支操作
    • git rebase -i HEAD^4

使代碼的提交記錄更加規整 !!!

Git alias

1. $ vi ~/.gitconfig

vi ~/.gitconfig

[alias]
  s = status
  d= diff
  co = checkout
  br = branch
  last = log -1 HEAD
  cane = commit --amend --no-edit
  lo = log - -oneline -n 10
  pr = pull --rebase

2. $ vim ~/.zshrc

vim ~/.zshrc

alias gst-"git status"
alias gac-"git add . && git commit -m" # + commit message
alias gbr="git branch" # + branch name alias go-"git checkout" # + branch name

3. $ vim ~/.zhsrc"

vim ~/.zhsrc

git config --global alias.s status 
git config --global alias.d diff 
git config -global alias.co checkout 
git config --global alias.br branch 
git config --global alias.last "log -1 HEAD" 
git config - -global alias.cane "commit --amend --no-edit" 
git config --global alias.pr "pull --rebase" 
git config --global altas.lo "log - -oneline -n 10'

skills

  • 配置 git hook
    • 代碼分析
    • 代碼格式優化
    • 單元測試
    • Git hook
  • 建議使用 git pull - -rebase 拉取代碼
  • 借用 stash 特性隨意切換分支
  • 使用 reflog 解決誤操作的重定向 HEAD
  • 通過git bisect的二分查找來快速揪出問題代碼
    • git bisect 是一種工具，用於查找引入錯誤或問題的提交。它可以幫助你更快地定位錯誤或問題最先出現的地方（commit），節省修復問題的時間。
    • 它使用二分查找算法在 git 歷史記錄中搜索問題的起因，並讓使用者在每一步中檢查是否發現錯誤，以進一步優化搜索過程。
    • Git bisect
  • git clean -fd
    • git clean -fd 的用途是清除 Git 工作目錄中未被 Git 管理的檔案和資料夾。
    • -f 表示強制執行，即不會提示使用者確認是否刪除，
    • 而 d 表示刪除資料夾。這個指令通常用於淨化本地工作目錄，以便重新開始或避免因舊檔案而造成的混淆。
    • 需要注意的是，該指令會永久刪除資料，應謹慎使用。
  • git cherry-pick.
    • git cherry-pick 是用來將一個或多個 commit 從另一個分支中選擇性地複製到當前分支中的命令。
    • 這個命令通常用於解決跨分支的程式碼衝突，或是將某個紀錄的修改套用到其他分支中。
    • 可以選擇多個 commit ，或是指定單一 commit 進行複製。
  • git commit --amend 修改最後一次提交
    • git commit --amend指令用於修正先前提交的最新一次commit的內容或commit message。
    • 例如，如果您發現漏寫了某些重要內容或拼錯了單詞，您可以使用這個指令來修改，而不必再建立一個新的commit。
    • 這個指令需要小心使用，因為它會覆寫Git中的先前歷史紀錄，可能會對您的團隊帶來影響，建議在熟悉操作之後再使用。
  • git clone --depth 限制拉取深度, 加快克隆代碼
  • 別放大文件, 刪除很麻煩
  • 使用 .gitignore 忽略不需要的文件
  • 使用 .gitkeep 保留空文件夾

Git bisect

  1. 首先，在 Git 儲存庫中啟用 bisect 模式：

    git bisect start

  2. 然後，使用 bad 命令標記當前程式碼的狀態為有 bug：

    git bisect bad

  3. 然後，切換到之前的某個提交，確認該提交的狀態為沒有 bug：

    git checkout <some-commit>
<test your code>
git bisect good

  4. Git 會自動計算出當前程式碼狀態和之前的某個提交的狀態之間的中點，並切換到該提交：

Bisecting: <commit-hash>
  1. 測試該提交的狀態：
<test your code>
git bisect good  # 如果該提交沒有 bug
git bisect bad   # 如果該提交有 bug
  1. 重複步驟 4 和步驟 5，直到找到引入 bug 的提交：
Bisecting: <commit-hash>
[...]
Bisecting: <commit-hash>
b2e52c996cebe977f4d4a4a4fb0908d4e03298a6 是第一個有 bug 的提交
  1. 最後，停止 bisect 模式：
    git bisect reset

Git hook

Git hook 是在 Git 進行某些操作時自動執行的腳本。Git 預設提供了多種 hook，你也可以自定義 hook 來滿足特定需求。

以下是一些 Git hook 的使用方法：

  1. pre-commit hook：在執行 git commit 前執行，可以用來驗證代碼風格、運行單元測試等。
  2. post-commit hook：在執行 git commit 後執行，可以用來更新文檔、發送通知等。
  3. pre-push hook：在執行 git push 前執行，可以用來運行整合測試、檢查代碼質量等。
  4. post-merge hook：在執行 git merge 後執行，可以用來更新子模塊、安裝依賴包等。
  5. pre-rebase hook：在執行 git rebase 前執行，可以用來檢查代碼衝突、保護分支歷史等。
  6. post-checkout hook：在執行 git checkout 後執行，可以用來更新本地數據、執行文件轉換等。
  7. pre-auto-gc hook：在自動執行垃圾回收前執行，可以用來清理臨時文件、釋放資源等。

你可以在 Git 儲存庫的 .git/hooks 目錄下找到這些 hook 的模板文件，並在其中添加自己的代碼來定義特定的操作。需要注意的是，這些 hook 需要先設置為可執行，才能正常運行。另外，每次 clone 或者 pull 一個儲存庫時，這些 hook 都需要手動複製到 .git/hooks 目錄下，以便使用。

© Kimi Tsai all right reserved.            Updated : 2023-07-12 09:04:54

results matching ""

    No results matching ""

    results matching ""

      No results matching ""