什么是約定式提交

約定式提交（Conventional Commits）是一種用于代碼版本控制的規范，旨在通過明確和標準化提交信息來提高代碼協作質量和效率。其基本原則是通過規定提交信息的結構和語義來提高代碼版本控制的可讀性、可維護性和自動化程度。

約定式提交規范通常要求提交信息包括一個描述性的"類型"、一個可選的"作用域"、一個用于簡潔說明的"主題"，以及可選的"正文"和"尾部"等組成部分。這些組成部分的格式和語義都是根據規范要求進行約定的，比如使用"feat"來表示新功能、"fix"表示修復錯誤、"docs"表示文檔變更等。

通過遵循約定式提交規范，開發人員可以更容易地理解和管理代碼的變更歷史，同時也為自動化工具提供了更多可靠的信息，例如自動生成版本號、發布日志和代碼庫更新等操作。

提交說明的結構如下所示:

原文：

[optional scope]: 

[optional body]

[optional footer(s)]

譯文：

<類型>[可選 范圍]: <描述>

[可選 正文]

[可選 腳注]

提交說明包含了下面的結構化元素，以向類庫使用者表明其意圖：

fix:類型為fix的提交表示在代碼庫中修復了一個 bug（這和語義化版本中的PATCH[1]相對應）。

feat:類型為feat的提交表示在代碼庫中新增了一個功能（這和語義化版本中的MINOR[2]相對應）。

BREAKING CHANGE:在腳注中包含BREAKING CHANGE:或 <類型>(范圍) 后面有一個!的提交，表示引入了破壞性 API 變更（這和語義化版本中的MAJOR[3]相對應）。破壞性變更可以是任意類型提交的一部分。

除fix:和feat:之外，也可以使用其它提交類型，例如@commitlint/config-conventional[4]（基于Angular 約定[5]）中推薦的build:、chore:、ci:、docs:、style:、refactor:、perf:、test:，等等。

腳注中除了BREAKING CHANGE: ，其它條目應該采用類似git trailer format[6]這樣的慣例。

其它提交類型在約定式提交規范中并沒有強制限制，并且在語義化版本中沒有隱式影響（除非它們包含 BREAKING CHANGE）。可以為提交類型添加一個圍在圓括號內的范圍，以為其提供額外的上下文信息。例如feat(parser): adds ability to parse arrays.。

示例

包含了描述并且腳注中有破壞性變更的提交說明

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

包含了!字符以提醒注意破壞性變更的提交說明

feat!: send an email to the customer when a product is shipped

包含了范圍和破壞性變更!的提交說明

feat(api)!: send an email to the customer when a product is shipped

包含了!和 BREAKING CHANGE 腳注的提交說明

chore!:dropsupportforNode6

BREAKINGCHANGE:useJavaScriptfeaturesnotavailableinNode6.

不包含正文的提交說明

docs:correctspellingofCHANGELOG

包含范圍的提交說明

feat(lang): add polish language

包含多行正文和多行腳注的提交說明

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

type 類型概覽

為什么需要約定式提交？

Git提交信息需要遵循Angular約定是為了使提交信息格式清晰、易于閱讀和理解，從而提高代碼協作的效率。Angular約定包括以下三個部分：

標題（header）：用一行簡短的描述來總結更改內容，并使用特殊關鍵字指定更改類型和影響范圍。

正文（body）：提供更詳細的更改描述，包括更改原因、影響和解決方案等信息。

頁腳（footer）：提供一些附加信息，如相關鏈接、關聯的BUG編號等。

通過遵循Angular約定，可以使提交信息更加規范化和易于管理，從而方便其他團隊成員閱讀和理解更改的含義，從而提高團隊協作效率。此外，遵循Angular約定的提交信息還可以更好地與許多自動化工具進行集成，如自動化版本控制、代碼審查工具等。

如何遵守約定式提交？

第一步：Commitizen=>自動生成提交說明的工具

Commitizen是一個基于命令行的交互式工具，它可以幫助開發者規范化提交Git提交信息，符合Angular Commit Message Conventions的規范，從而更好地管理代碼變更歷史。

Commitizen提供了一個友好的命令行交互界面，讓開發者根據規范選擇提交信息的類型、影響范圍等內容，自動生成符合規范的Git提交信息。

Commitizen可以與Git結合使用，使得開發者可以使用commitizen命令代替git commit命令提交代碼變更，并且生成的提交信息格式更加規范化和易于管理。

這里我建議您全局安裝

pnpminstall-gcommitizen
pnpminstall-gcz-conventional-changelog

隨后在電腦用戶根目錄穿件.czrc文件，不然使用的時候會進入命令行（筆者的系統為Ubuntu20.04）

echo'{"path":"cz-conventional-changelog"}'>~/.czrc

隨后使用commitizen生成符合AngularJS規范的提交說明

commitizeninitcz-conventional-changelog--save--save-exact

隨后你就可以使用以下命令獲得中規中距的commit信息了。

gitcz

第二步：Cz-customizable=> 客制化自動提交信息

cz-customizable 是 Commitizen的一個插件，可以幫助開發者自定義符合Angular Commit Message Conventions的提交信息格式和內容。

拜托，人又不是機器！別那么死板。和代碼打交道最重要的事情就是懂得如何苦中作樂，在遇到挑戰和困難時，優秀的人能夠采取積極的心態，并且能夠尋找解決問題的方式和方法。

cz-customizable提供了一些配置選項，讓開發者可以根據項目的需要自定義提交信息的格式和內容。

cz-customizable的配置選項包括：

types: 定義提交信息的類型，如feat（新功能）、fix（修復Bug）等。

scopes: 定義提交信息的影響范圍，如模塊、組件等。

allowCustomScopes: 是否允許自定義影響范圍。

scopeOverrides: 定義不同類型的提交信息對影響范圍的要求。

messages: 定義提交信息的模板，包括標題、正文、頁腳等內容。

allowBreakingChanges: 是否允許提交破壞性變更。

1. 安裝 cz-customizable

npminstallcz-customizable--save-dev

2. 添加以下配置到package.json中

"config":{
"commitizen":{
"path":"node_modules/cz-customizable"
}
}

3.項目根目錄下創建.cz-config.js文件來自定義提示

├── CHANGELOG.md
├── commitlint.config.js
├── index.html
├── node_modules
├── package.json
├── pnpm-lock.yaml
├── public
├── README.md
├── src
├── tsconfig.json
├── tsconfig.node.json
├── vite.config.ts
└── .cz-config.js  // 創建

以下是我的一些參考配置

module.exports={
//可選類型
types:[
{
value:'feat',
name:'feat:新功能'
},
{
value:'fix',
name:'fix:修復'
},
{
value:'docs',
name:'docs:文檔變更'
},
{
value:'style',

name:'style:代碼格式(不影響代碼運行的變動)'
},
{
value:'refactor',

name:'refactor:重構(既不增加feature,也不是修復bug)'
},
{
value:'perf',
name:'perf:性能優化'
},
{
value:'test',
name:'test:增加測試'
},
{
value:'chore',
name:'chore:構建過程或輔助工具的變動'
},
{
value:'revert',
name:'revert:回退'
},
{
value:'build',
name:'build:打包'
}
],

//步驟

messages:{
type:'請選擇提交的類型：',
customScope:'情輸入修改的范圍(可選)',
subject:'請簡要描述提交(必填)',
body:'請輸入詳細描述(可選)',
footer:'請輸入要關閉的issus(可選)',
confirmCommit:'確認要使用以上信息提交？(y/n)'
},
//默認長度72
subjectLimit:72
};

此時再次運行git cz時就可以看到

?請選擇提交的類型：(Usearrowkeys)
?feat:新功能
fix:修復
docs:文檔變更
style:代碼格式(不影響代碼運行的變動)
refactor:重構(既不增加feature,也不是修復bug)
perf:性能優化
test:增加測試

第三步：Commitlint=> 對自動生成 commit 信息的校驗

有時候你的隊友可能是傻逼？請你注意防范

很遺憾的是，上面的操作并沒有任何校驗功能，你的隊友仍然可以提交 trash 在 commit 信息中。如果不敲你是隊伍中的審核人員，那么我想你需要設置一些規范

Commitlint 幫助你進行git commit -m "提交說明"操作時，對提交說明會按照commitlint.config.js配置的規則進行校驗，不通過則不能提交 這里我們分情況討論：

若您沒有使用 cz-customizable適配器做了破壞Angular風格的提交說明配置，則可以使用以下配置方案

1.安裝@commitlint/config-conventional

npmi@commitlint/config-conventional@commitlint/cli-D

2.在根目錄創建commitlint.config.js文件，配置commitlint

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

若您使用cz-customizable了則需要使用以下配置方案

npminstallcommitlint-config-cz--save-dev

然后加入commitlint校驗規則配置：

module.exports = {
  extends: [
    'cz'
  ]
};

這里我說明一下：cz實際上是commitlint-config-cz的簡寫，這個簡寫是在commitlint中預定義的。cz配置文件本身并不存在，它實際上是通過擴展commitlint-config-cz配置文件來實現的。commitlint-config-cz在規范 Git 提交信息的時候，會讀取cz-config.js中的配置信息。

commitizen、cz-customizable、commitlint 三者之間的關系

到這里可能已經分不清 誰和誰的關系了，這里筆者在幫大家理清一下

commitizen就像是生產線上的模板，它定義了產品的外觀和結構，提供了一種易于理解和使用的模板來生成規范化的提交信息。

cz-customizable就像是生產線上的調整機器，你可以給產品換個顏色，換個包裝等等。它可以根據不同的需求對模板進行定制，適應不同的項目需求。

commitlint就像是生產線上的檢測設備，這意味著不管你如何去 DIY 這個產品，他總要有一個審核標準來說明他是一個合格產品。而commitlint支持多種規范配置文件，其中就包括commitlint-config-cz，它繼承了commitlint-config-conventional的基礎規范，并增加了對commitizen規范的支持。

最后的一些補充

husky: 最后的幫手

是一個可以在 Git hooks 中使用的 npm 包，它可以幫助你在特定的 Git 事件發生時執行命令，例如提交代碼之前進行代碼格式化、測試等操作.

"husky"是一個為了方便使用Git hooks的工具，它能夠幫助你在項目中自動化地執行一些Git相關的操作。使用husky，你可以在Git的一些關鍵操作（例如提交、推送、合并等）前或后，執行一些腳本或命令，比如代碼格式化、自動化測試、打包發布等。

他可以幫助我們額外攔截一些如git commit等指令。需要注意的是，husky只在Git倉庫中才能正常工作，所以在使用之前請確保你的項目已經初始化為Git倉庫

1.安裝 husky

在項目中安裝 husky，可以使用 npm或者 yarn 進行安裝：

pnpminstallhusky--save-dev

或者

yarnaddhusky--dev

2.在package.json中定義需要執行的Git hooks和對應的腳本

例如，在提交代碼前執行代碼格式化和自動化測試：

jsonCopycode{
"husky":{
"hooks":{
"pre-commit":"npmrunlint&&npmruntest"
}
}
}

這樣，每次在執行git commit命令時，都會自動執行npm中定義的lint和test命令。

除了pre-commit鉤子，husky還支持其他一些Git hooks，比如pre-push、post-merge、post-checkout等，可以根據實際需求進行配置。

需要注意的是，husky只在Git倉庫中才能正常工作，所以在使用之前請確保你的項目已經初始化為Git倉庫。

當然 除了在pageage.json中設置之外，還可以使用

npx husky add .husky/pre-commit來生成一個 hook 的文件

隨后你也可以在相應的文件中書寫要執行的腳本了

./.husky/
├──_
│└──husky.sh
├──commit-msg
└──pre-commit//再此寫入

3.使用lint-staged, 對暫存區代碼進行eslint校驗和prettier格式化

現在我們已經約束了提交規范，但是我們希望在提交前對當前的代碼進行格式驗證和修復，此時需要使用到lint-staged

安裝npm i lint-staged --save-dev

在package.json中新增配置，以上操作可以實現，每次進行git commit操作，將執行pre-commit鉤子里面的代碼，從而執行lint-staged配置項的命令

"lint-staged":{
"**/*.scss":"stylelint--syntaxscss",
"**/*.{js,jsx,tsx,ts}":"npmrunlint-staged:js",
"**/*.{js,jsx,tsx,ts,less,scss,md,json}":[
"prettier--write"
]
}

在package.json中新增lint-staged和lint-staged.js命令

"scripts":{
"lint-staged":"lint-staged",
"lint-staged:js":"eslint--ext.js,.jsx,.ts,.tsx"
}

最后在pre-commit中新增腳本

npm run lint-staged

ChatGpt: commit 生成器

我在發布這篇文章的20天內收到了很多掘金小友的建議:“ 2023 年了，把這些交給 ChatGpt 去做！”。好吧，也許是我太遲鈍了。這里我也更新這一小節。以下是我搜集到的一些利用 ChatGpt 做 Commit 的方式：

方式一：最常見的方式 利用預設的 prompt 對 chatgpt 設定角色。這里我也貼出我收集到提示詞：
I want you to act as a commit message generator. I will provide you with information about the task and the prefix for the task code, and I would like you to generate an appropriate commit message using the conventional commit format. Do not write any explanations or other words, just reply with the commit message.
我想讓你充當一個提交信息生成器。我將為你提供任務的信息和任務代碼的前綴，我希望你能用常規的提交格式生成一條合適的提交信息。不要寫任何解釋或其他文字，只需回復提交信息。

方式二：使用commitgpt。這應該是小伙伴們最希望看到的方式，集成在項目中而不需要切換到網頁上對著一個機器人發問。但很遺憾作者在原文中提到

OpenAI added additional Cloudflare protections that make it more difficult to access the unofficial API. The tool is not working temporary until I find a way to workaround it.
OpenAI增加了Cloudflare的額外保護措施，使得訪問非官方API變得更加困難。目前該工具暫時無法使用，直到我找到解決辦法。

但您如果感興趣仍然可以進行嘗試,這里放上連接：https://github.com/RomanHotsiy/commitgpt

送給讀者的話

在我第一次接觸到規范這類繁雜且" 無意義 "的行為時，我也和很多人一樣覺得這是一些無關緊要的東西。但使用 commit 規范可以幫助自己更好地記錄和追蹤代碼的變化。通過規范的 commit message，可以清晰地記錄下每次提交代碼所做的更改和原因。這有助于你在以后回顧代碼時更好地理解代碼的變化和背后的原因。最重要的是提交規范不僅是代碼開發中的工具，更是一種生活態度和價值觀。遵循規范，能夠讓我們更加專業和高效地處理事物，建立更加和諧和美好的人際關系。