安裝Husky + commitlint 規範 commit 訊息

在開發用例時，撰寫清楚且統一的提交資訊非常重要，因為它能讓團隊成員快速理解每次提交的更改內容。

為了了解這個問題，可以使用Husky、Commitlint 來建立一套提交訊息規範，確保所有發布者都遵循相同的格式。

套件

• husky ：是一個 Git Hooks 工具，可以在git commit或git push隨時執行外部的驗證腳本。
• commitlint : 可用來驗證提交訊息格式

安裝流程

步驟1：安裝 Husky

作用：是一個 Git Hooks 工具，可以在git commit或git push有時執行額外的實驗腳本。

npm install --save-dev husky

這次將 Husky 安裝到devDependencies，並保證它只在開發環境中使用。

步驟2：初始化 Husky

作用：這些步驟將在專題中建立 目錄，讓 Husky可以.husky/管理 Git Hooks。

npm husky init

這會做兩件事：

• 在package.json中新增prepare腳本：

"scripts": { 
		"prepare": "husky install" 
}

• 執行husky install指令，在個人資料中建立 .husky/目錄：

.husky/ 
├── _ 
└── pre-commit

如果preparescript沒有執行（或Husky沒有正常運作），可以手動執行：

npm run prepare

步驟 3：安裝 commitlint cli & conventional config

npm install --save-dev  @commitlint /config-conventional @commitlint /cli

步驟 4：設定 commitlint 設定欄

echo  "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.cjs

步驟 5：新增 Git Hook

作用：Husky 允許我們自行註冊 Git Hooks，例如pre-commit或commit-msg。

（1）新增pre-commitHook

這次會議是每次執業git commit前擔任執業npm test：

npx husky add .husky / pre-commit “npm test”

本次 .husky/pre-commit產物檔案，內容如下：

npm test

如果npm test不存在，建議先package.json加入：

"scripts": { 
		"test": "echo \"No tests available\" && exit 0" 
}

（2）新增commit-msgHook

（驗證 Commit 訊息格式）

如果你已經安裝commitlint，可以使用 Husky 來保證 commit 訊息符合 Conventional Commits 規範：

npm husky 加 .husky/commit-msg 

此處建立 .husky/commit-msg，內容如下：

# 1. 將全形冒號（：）轉換為半形冒號（:）
sed -i '' -E 's/：/:/g' "$1" # 將全形冒號轉換為半形冒號

# 2. 確保冒號後面有且只有一個空格
sed -i '' -E 's/^([a-zA-Z]+):[[:space:]]*/\1: /' "$1" # 冒號後面有空格且只有一個

# 3. 移除開頭空白
sed -i '' -E 's/^[[:space:]]+//g' "$1" # 移除開頭的空格

# 4. 如果 message 是空的，設置一個預設值
sed -i '' -E 's/^[[:space:]]*$/feat: Update commit message/g' "$1" # 補充預設訊息

# 5. 執行 commitlint 驗證
npx --no -- commitlint --edit "$1"

這樣，每次git commit，commitlint都會自動檢查 commit 訊息是否合法。

步驟 6：測試 Husky 是否運行

執行以下指令，測試Husky是否成功安裝並運行：

git commit  -m "test: 測試 Husky"

如果：

• 成功提交，代表 Husky 正常運作
• 出錯（例如 commit 訊息不符合規範），則會顯示錯誤錯誤訊息，阻止提交— commit
  訊息的:需要形式
  — :後面有一個空格，這是正確格式
  — <type>必填是小寫（例如feat、、、） — 不能為空fixchoredocs
<subject>

提交訊息的格式不符合常規提交

根據常規提交規則，提交訊息應是：

<Type> : <subject>

Type類型

commitlint 定義 Type 有以下這些，如果不符合以下則會報錯！

• build：部署系統或外部依賴的變更（例如：gulp、broccoli、npm）
• ci:修改 CI（持續整合）設定列或腳本（例如：GitHub Actions、SauceLabs）
• docs:只關注事情的改變
• 特性：新增功能
• fix:修改錯誤
• perf:優化的程式碼更改
• 重構：既不是修改錯誤，也不是新增功能的重構
• 測試：新增或修改測試內容