什么是約定式提交
約定式提交(Conventional Commits)是一種用于代碼版本控制的規(guī)范,旨在通過明確和標準化提交信息來提高代碼協(xié)作質(zhì)量和效率。其基本原則是通過規(guī)定提交信息的結(jié)構(gòu)和語義來提高代碼版本控制的可讀性、可維護性和自動化程度。
約定式提交規(guī)范通常要求提交信息包括一個描述性的"類型"、一個可選的"作用域"、一個用于簡潔說明的"主題",以及可選的"正文"和"尾部"等組成部分。這些組成部分的格式和語義都是根據(jù)規(guī)范要求進行約定的,比如使用"feat"來表示新功能、"fix"表示修復(fù)錯誤、"docs"表示文檔變更等。
通過遵循約定式提交規(guī)范,開發(fā)人員可以更容易地理解和管理代碼的變更歷史,同時也為自動化工具提供了更多可靠的信息,例如自動生成版本號、發(fā)布日志和代碼庫更新等操作。
提交說明的結(jié)構(gòu)如下所示:
原文:
[optional scope]: [optional body] [optional footer(s)]
譯文:
<類型>[可選 范圍]: <描述> [可選 正文] [可選 腳注]
提交說明包含了下面的結(jié)構(gòu)化元素,以向類庫使用者表明其意圖:
fix:類型為fix的提交表示在代碼庫中修復(fù)了一個 bug(這和語義化版本中的PATCH[1]相對應(yīng))。
feat:類型為feat的提交表示在代碼庫中新增了一個功能(這和語義化版本中的MINOR[2]相對應(yīng))。
BREAKING CHANGE:在腳注中包含BREAKING CHANGE:或 <類型>(范圍) 后面有一個!的提交,表示引入了破壞性 API 變更(這和語義化版本中的MAJOR[3]相對應(yīng))。破壞性變更可以是任意類型提交的一部分。
除fix:和feat:之外,也可以使用其它提交類型,例如@commitlint/config-conventional[4](基于Angular 約定[5])中推薦的build:、chore:、ci:、docs:、style:、refactor:、perf:、test:,等等。
腳注中除了BREAKING CHANGE:
其它提交類型在約定式提交規(guī)范中并沒有強制限制,并且在語義化版本中沒有隱式影響(除非它們包含 BREAKING CHANGE)??梢詾樘峤活愋吞砑右粋€圍在圓括號內(nèi)的范圍,以為其提供額外的上下文信息。例如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 類型概覽
值 | 描述 |
---|---|
feat | 新增一個功能 |
fix | 修復(fù)一個Bug |
docs | 文檔變更 |
style | 代碼格式(不影響功能,例如空格、分號等格式修正) |
refactor | 代碼重構(gòu) |
perf | 改善性能 |
test | 測試 |
build | 變更項目構(gòu)建或外部依賴(例如scopes: webpack、gulp、npm等) |
ci | 更改持續(xù)集成軟件的配置文件和package中的scripts命令,例如scopes: Travis, Circle等 |
chore | 變更構(gòu)建流程或輔助工具 |
revert | 代碼回退 |
為什么需要約定式提交?
Git提交信息需要遵循Angular約定是為了使提交信息格式清晰、易于閱讀和理解,從而提高代碼協(xié)作的效率。Angular約定包括以下三個部分:
標題(header):用一行簡短的描述來總結(jié)更改內(nèi)容,并使用特殊關(guān)鍵字指定更改類型和影響范圍。
正文(body):提供更詳細的更改描述,包括更改原因、影響和解決方案等信息。
頁腳(footer):提供一些附加信息,如相關(guān)鏈接、關(guān)聯(lián)的BUG編號等。
通過遵循Angular約定,可以使提交信息更加規(guī)范化和易于管理,從而方便其他團隊成員閱讀和理解更改的含義,從而提高團隊協(xié)作效率。此外,遵循Angular約定的提交信息還可以更好地與許多自動化工具進行集成,如自動化版本控制、代碼審查工具等。
如何遵守約定式提交?
第一步:Commitizen=>自動生成提交說明的工具
Commitizen是一個基于命令行的交互式工具,它可以幫助開發(fā)者規(guī)范化提交Git提交信息,符合Angular Commit Message Conventions的規(guī)范,從而更好地管理代碼變更歷史。
Commitizen提供了一個友好的命令行交互界面,讓開發(fā)者根據(jù)規(guī)范選擇提交信息的類型、影響范圍等內(nèi)容,自動生成符合規(guī)范的Git提交信息。
Commitizen可以與Git結(jié)合使用,使得開發(fā)者可以使用commitizen命令代替git commit命令提交代碼變更,并且生成的提交信息格式更加規(guī)范化和易于管理。
這里我建議您全局安裝
pnpminstall-gcommitizen pnpminstall-gcz-conventional-changelog
隨后在電腦用戶根目錄穿件.czrc文件,不然使用的時候會進入命令行(筆者的系統(tǒng)為Ubuntu20.04)
echo'{"path":"cz-conventional-changelog"}'>~/.czrc
隨后使用commitizen生成符合AngularJS規(guī)范的提交說明
commitizeninitcz-conventional-changelog--save--save-exact
隨后你就可以使用以下命令獲得中規(guī)中距的commit信息了。
gitcz
第二步:Cz-customizable=> 客制化自動提交信息
cz-customizable 是 Commitizen的一個插件,可以幫助開發(fā)者自定義符合Angular Commit Message Conventions的提交信息格式和內(nèi)容。
拜托,人又不是機器!別那么死板。和代碼打交道最重要的事情就是懂得如何苦中作樂,在遇到挑戰(zhàn)和困難時,優(yōu)秀的人能夠采取積極的心態(tài),并且能夠?qū)ふ医鉀Q問題的方式和方法。
cz-customizable提供了一些配置選項,讓開發(fā)者可以根據(jù)項目的需要自定義提交信息的格式和內(nèi)容。
cz-customizable的配置選項包括:
types: 定義提交信息的類型,如feat(新功能)、fix(修復(fù)Bug)等。
scopes: 定義提交信息的影響范圍,如模塊、組件等。
allowCustomScopes: 是否允許自定義影響范圍。
scopeOverrides: 定義不同類型的提交信息對影響范圍的要求。
messages: 定義提交信息的模板,包括標題、正文、頁腳等內(nèi)容。
allowBreakingChanges: 是否允許提交破壞性變更。
1. 安裝 cz-customizable
npminstallcz-customizable--save-dev
2. 添加以下配置到package.json中
"config":{ "commitizen":{ "path":"node_modules/cz-customizable" } }
3.項目根目錄下創(chuàng)建.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 // 創(chuàng)建
以下是我的一些參考配置
module.exports={ //可選類型 types:[ { value:'feat', name:'feat:新功能' }, { value:'fix', name:'fix:修復(fù)' }, { value:'docs', name:'docs:文檔變更' }, { value:'style', name:'style:代碼格式(不影響代碼運行的變動)' }, { value:'refactor', name:'refactor:重構(gòu)(既不增加feature,也不是修復(fù)bug)' }, { value:'perf', name:'perf:性能優(yōu)化' }, { value:'test', name:'test:增加測試' }, { value:'chore', name:'chore:構(gòu)建過程或輔助工具的變動' }, { value:'revert', name:'revert:回退' }, { value:'build', name:'build:打包' } ], //步驟 messages:{ type:'請選擇提交的類型:', customScope:'情輸入修改的范圍(可選)', subject:'請簡要描述提交(必填)', body:'請輸入詳細描述(可選)', footer:'請輸入要關(guān)閉的issus(可選)', confirmCommit:'確認要使用以上信息提交?(y/n)' }, //默認長度72 subjectLimit:72 };
此時再次運行g(shù)it cz時就可以看到
?請選擇提交的類型:(Usearrowkeys) ?feat:新功能 fix:修復(fù) docs:文檔變更 style:代碼格式(不影響代碼運行的變動) refactor:重構(gòu)(既不增加feature,也不是修復(fù)bug) perf:性能優(yōu)化 test:增加測試
第三步:Commitlint=> 對自動生成 commit 信息的校驗
有時候你的隊友可能是傻逼?請你注意防范
很遺憾的是,上面的操作并沒有任何校驗功能,你的隊友仍然可以提交 trash 在 commit 信息中。如果不敲你是隊伍中的審核人員,那么我想你需要設(shè)置一些規(guī)范
Commitlint 幫助你進行g(shù)it commit -m "提交說明"操作時,對提交說明會按照commitlint.config.js配置的規(guī)則進行校驗,不通過則不能提交 這里我們分情況討論:
若您沒有使用 cz-customizable適配器做了破壞Angular風格的提交說明配置,則可以使用以下配置方案
1.安裝@commitlint/config-conventional
npmi@commitlint/config-conventional@commitlint/cli-D
2.在根目錄創(chuàng)建commitlint.config.js文件,配置commitlint
module.exports = { extends: ['@commitlint/config-conventional'] }
若您使用cz-customizable了則需要使用以下配置方案
npminstallcommitlint-config-cz--save-dev
然后加入commitlint校驗規(guī)則配置:
module.exports = { extends: [ 'cz' ] };
這里我說明一下:cz實際上是commitlint-config-cz的簡寫,這個簡寫是在commitlint中預(yù)定義的。cz配置文件本身并不存在,它實際上是通過擴展commitlint-config-cz配置文件來實現(xiàn)的。commitlint-config-cz在規(guī)范 Git 提交信息的時候,會讀取cz-config.js中的配置信息。
commitizen、cz-customizable、commitlint 三者之間的關(guān)系
到這里可能已經(jīng)分不清 誰和誰的關(guān)系了,這里筆者在幫大家理清一下
commitizen就像是生產(chǎn)線上的模板,它定義了產(chǎn)品的外觀和結(jié)構(gòu),提供了一種易于理解和使用的模板來生成規(guī)范化的提交信息。
cz-customizable就像是生產(chǎn)線上的調(diào)整機器,你可以給產(chǎn)品換個顏色,換個包裝等等。它可以根據(jù)不同的需求對模板進行定制,適應(yīng)不同的項目需求。
commitlint就像是生產(chǎn)線上的檢測設(shè)備,這意味著不管你如何去 DIY 這個產(chǎn)品,他總要有一個審核標準來說明他是一個合格產(chǎn)品。而commitlint支持多種規(guī)范配置文件,其中就包括commitlint-config-cz,它繼承了commitlint-config-conventional的基礎(chǔ)規(guī)范,并增加了對commitizen規(guī)范的支持。
最后的一些補充
husky: 最后的幫手
是一個可以在 Git hooks 中使用的 npm 包,它可以幫助你在特定的 Git 事件發(fā)生時執(zhí)行命令,例如提交代碼之前進行代碼格式化、測試等操作.
"husky"是一個為了方便使用Git hooks的工具,它能夠幫助你在項目中自動化地執(zhí)行一些Git相關(guān)的操作。使用husky,你可以在Git的一些關(guān)鍵操作(例如提交、推送、合并等)前或后,執(zhí)行一些腳本或命令,比如代碼格式化、自動化測試、打包發(fā)布等。
他可以幫助我們額外攔截一些如git commit等指令。需要注意的是,husky只在Git倉庫中才能正常工作,所以在使用之前請確保你的項目已經(jīng)初始化為Git倉庫
1.安裝 husky
在項目中安裝 husky,可以使用 npm或者 yarn 進行安裝:
pnpminstallhusky--save-dev
或者
yarnaddhusky--dev
2.在package.json中定義需要執(zhí)行的Git hooks和對應(yīng)的腳本
例如,在提交代碼前執(zhí)行代碼格式化和自動化測試:
jsonCopycode{ "husky":{ "hooks":{ "pre-commit":"npmrunlint&&npmruntest" } } }
這樣,每次在執(zhí)行g(shù)it commit命令時,都會自動執(zhí)行npm中定義的lint和test命令。
除了pre-commit鉤子,husky還支持其他一些Git hooks,比如pre-push、post-merge、post-checkout等,可以根據(jù)實際需求進行配置。
需要注意的是,husky只在Git倉庫中才能正常工作,所以在使用之前請確保你的項目已經(jīng)初始化為Git倉庫。
當然 除了在pageage.json中設(shè)置之外,還可以使用
npx husky add .husky/pre-commit來生成一個 hook 的文件
隨后你也可以在相應(yīng)的文件中書寫要執(zhí)行的腳本了
./.husky/ ├──_ │└──husky.sh ├──commit-msg └──pre-commit//再此寫入
3.使用lint-staged, 對暫存區(qū)代碼進行eslint校驗和prettier格式化
現(xiàn)在我們已經(jīng)約束了提交規(guī)范,但是我們希望在提交前對當前的代碼進行格式驗證和修復(fù),此時需要使用到lint-staged
安裝npm i lint-staged --save-dev
在package.json中新增配置,以上操作可以實現(xiàn),每次進行g(shù)it commit操作,將執(zhí)行pre-commit鉤子里面的代碼,從而執(zhí)行l(wèi)int-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 生成器
我在發(fā)布這篇文章的20天內(nèi)收到了很多掘金小友的建議:“ 2023 年了,把這些交給 ChatGpt 去做!”。好吧,也許是我太遲鈍了。這里我也更新這一小節(jié)。以下是我搜集到的一些利用 ChatGpt 做 Commit 的方式:
方式一:最常見的方式 利用預(yù)設(shè)的 prompt 對 chatgpt 設(shè)定角色。這里我也貼出我收集到提示詞:
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.
我想讓你充當一個提交信息生成器。我將為你提供任務(wù)的信息和任務(wù)代碼的前綴,我希望你能用常規(guī)的提交格式生成一條合適的提交信息。不要寫任何解釋或其他文字,只需回復(fù)提交信息。
方式二:使用commitgpt。這應(yīng)該是小伙伴們最希望看到的方式,集成在項目中而不需要切換到網(wǎng)頁上對著一個機器人發(fā)問。但很遺憾作者在原文中提到
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
送給讀者的話
在我第一次接觸到規(guī)范這類繁雜且" 無意義 "的行為時,我也和很多人一樣覺得這是一些無關(guān)緊要的東西。但使用 commit 規(guī)范可以幫助自己更好地記錄和追蹤代碼的變化。通過規(guī)范的 commit message,可以清晰地記錄下每次提交代碼所做的更改和原因。這有助于你在以后回顧代碼時更好地理解代碼的變化和背后的原因。最重要的是提交規(guī)范不僅是代碼開發(fā)中的工具,更是一種生活態(tài)度和價值觀。遵循規(guī)范,能夠讓我們更加專業(yè)和高效地處理事物,建立更加和諧和美好的人際關(guān)系。
-
自動化
+關(guān)注
關(guān)注
29文章
5563瀏覽量
79240 -
代碼
+關(guān)注
關(guān)注
30文章
4780瀏覽量
68529 -
工具
+關(guān)注
關(guān)注
4文章
311瀏覽量
27770
原文標題:一份供前端開發(fā)參考的 commit 規(guī)范
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論