在開發用例時，撰寫清楚且統一的提交資訊非常重要，因為它能讓團隊成員快速理解每次提交的更改內容。
為了了解這個問題，可以使用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:優化的程式碼更改
- 重構：既不是修改錯誤，也不是新增功能的重構
- 測試：新增或修改測試內容