別亂提交代碼了，看下大廠 Git 提交規(guī)范是怎么做的！
點擊上方?java項目開發(fā)，選擇?設為星標
優(yōu)質(zhì)文章，及時送達
來源：juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0
用什么規(guī)范？ Quick Start Commit message規(guī)范在rrd-fe落地使用情況 示例 擴展閱讀
git是現(xiàn)在市面上最流行的版本控制工具，書寫良好的commit message能大大提高代碼維護的效率。但是在日常開發(fā)中由于缺少對于commit message的約束，導致填寫內(nèi)容隨意、質(zhì)量參差不齊，可讀性低亦難以維護。在項目中引入commit message規(guī)范已是迫在眉睫
用什么規(guī)范？
現(xiàn)在市面上比較流行的方案是約定式提交規(guī)范（Conventional Commits），它受到了Angular提交準則的啟發(fā)，并在很大程度上以其為依據(jù)。約定式提交規(guī)范是一種基于提交消息的輕量級約定。它提供了一組用于創(chuàng)建清晰的提交歷史的簡單規(guī)則；這使得編寫基于規(guī)范的自動化工具變得更容易。這個約定與SemVer相吻合，在提交信息中描述新特性、bug 修復和破壞性變更。它的 message 格式如下:
<類型>[可選的作用域]:?<描述>
[可選的正文]
[可選的腳注]
Quick Start
1. 全局安裝commitizen & cz-conventional-changelog
commitizen是一個撰寫合格commit message的工具，用于代替git commit 指令，而cz-conventional-changelog適配器提供conventional-changelog標準（約定式提交標準）。基于不同需求，也可以使用不同適配器。
npm?install?-g?commitizen?cz-conventional-changelog
echo?'{?"path":?"cz-conventional-changelog"?}'?>?~/.czrc
安裝完畢后，可直接使用git cz來取代git commit。
全局模式下，需要 ~/.czrc 配置文件, 為commitizen指定Adapter。
2. 項目內(nèi)安裝commitlint & husky
commitlint負責用于對commit message進行格式校驗，husky負責提供更易用的git hook。
Use?npm
npm?i?-D?husky?@commitlint/config-conventional?@commitlint/cli
Use?yarn
yarn?add?husky?@commitlint/config-conventional?@commitlint/cli?-D
commitlint只能做格式規(guī)范，無法觸及內(nèi)容。對于內(nèi)容質(zhì)量的把控只能靠我們自己。
3. 添加相應配置
創(chuàng)建commitlint.config.js
#?In?the?same?path?as?package.json
echo?'module.exports?=?{extends:?["@commitlint/config-conventional"]};'?>?./commitlint.config.js
引入husky
#?package.json
...,
"husky":?{
????"hooks":?{
??????"commit-msg":?"commitlint?-e?$GIT_PARAMS"
????}
}
4. 使用
執(zhí)行git cz進入interactive模式，根據(jù)提示依次填寫
1.Select?the?type?of?change?that?you're?committing?選擇改動類型?()
2.What?is?the?scope?of?this?change?(e.g.?component?or?file?name)??填寫改動范圍?()
3.Write?a?short,?imperative?tense?description?of?the?change:?寫一個精簡的描述?()
4.Provide?a?longer?description?of?the?change:?(press?enter?to?skip)?對于改動寫一段長描述?()
5.Are there any breaking changes? (y/n)?是破壞性修改嗎？默認n ( 生成的commit message格式如下：
():?
填寫完畢后，husky會調(diào)用commitlint對message進行格式校驗，默認規(guī)定type及subject為必填項。
任何git commit指令的option都能用在 git cz指令上, 例如git cz -a
Commit message規(guī)范在rrd-fe落地使用情況
針對團隊目前使用的情況，我們討論后擬定了commit message每一部分的填寫規(guī)則。
1. type
type為必填項，用于指定commit的類型，約定了feat、fix兩個主要type，以及docs、style、build、refactor、revert五個特殊type，其余type暫不使用。
#?主要type
feat:?????增加新功能
fix:??????修復bug
#?特殊type
docs:?????只改動了文檔相關的內(nèi)容
style:????不影響代碼含義的改動，例如去掉空格、改變縮進、增刪分號
build:????構(gòu)造工具的或者外部依賴的改動，例如webpack，npm
refactor:?代碼重構(gòu)時使用
revert:???執(zhí)行git?revert打印的message
#?暫不使用type
test:?????添加測試或者修改現(xiàn)有測試
perf:?????提高性能的改動
ci:???????與CI（持續(xù)集成服務）有關的改動
chore:????不修改src或者test的其余修改，例如構(gòu)建過程或輔助工具的變動
當一次改動包括主要type與特殊type時，統(tǒng)一采用主要type。
2. scope
scope也為必填項，用于描述改動的范圍，格式為項目名/模塊名，例如：node-pc/common rrd-h5/activity，而we-sdk不需指定模塊名。如果一次commit修改多個模塊，建議拆分成多次commit，以便更好追蹤和維護。
3. body
body填寫詳細描述，主要描述改動之前的情況及修改動機，對于小的修改不作要求，但是重大需求、更新等必須添加body來作說明。
4. break changes
break changes指明是否產(chǎn)生了破壞性修改，涉及break changes的改動必須指明該項，類似版本升級、接口參數(shù)減少、接口刪除、遷移等。
5. affect issues
affect issues指明是否影響了某個問題。例如我們使用jira時，我們在commit message中可以填寫其影響的JIRA_ID，若要開啟該功能需要先打通jira與gitlab。參考文檔：docs.gitlab.com/ee/user/pro…
填寫方式例如：
re?#JIRA_ID
fix?#JIRA_ID
示例
完整的commit message示例
相應的git log
-?END - 推薦案例
溫暖提示
為了方便大家更好的學習，本公眾號經(jīng)常分享一些完整的單個功能案例代碼給大家去練習，如果本公眾號沒有你要學習的功能案例，你可以聯(lián)系小編（微信：xxf960513）提供你的小需求給我，我安排我們這邊的開發(fā)團隊免費幫你完成你的案例。 注意：只能提單個功能的需求不能要求功能太多，比如要求用什么技術，有幾個頁面，頁面要求怎么樣？
請長按識別二維碼
想學習更多的java功能案例請關注
Java項目開發(fā)
如果你覺得這個案例以及我們的分享思路不錯，對你有幫助，請分享給身邊更多需要學習的朋友。別忘了《留言+點在看》給作者一個鼓勵哦！
