摘要:代碼提交規(guī)范前言在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及處理時(shí)會(huì)更加方便。每次提交代碼,都要寫提交說(shuō)明,否則就不允許提交。一般來(lái)說(shuō),應(yīng)該清晰明了,說(shuō)明本次提交的目的。不會(huì)提交新文件。
Commit message 代碼提交規(guī)范
**
前言
**
在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一、代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及Bug處理時(shí)會(huì)更加方便。Git 每次提交代碼,都要寫 Commit message(提交說(shuō)明),否則就不允許提交。一般來(lái)說(shuō),commit message 應(yīng)該清晰明了,說(shuō)明本次提交的目的。
Commit message 的作用
● 提供更多的歷史信息,方便快速瀏覽
● 過(guò)濾某些commit(比如文檔改動(dòng)),便于快速查找信息
● 直接從commit生成Change log
● 可讀性好,清晰,不必深入看代碼即可了解當(dāng)前commit的作用。
● 為 Code Reviewing(代碼審查)做準(zhǔn)備
● 方便跟蹤工程歷史
● 提高項(xiàng)目的整體質(zhì)量,提高個(gè)人工程素質(zhì)
Commit message 的格式
Commit message 包括三個(gè)部分:Header,Body 和 Footer
( ): // 空一行 // 空一行
一、Header
Header部分只有一行,包括三個(gè)字段:type(必需)、scope(可選)和subject(必需)
(1)type
? type用于說(shuō)明 commit 的類別,只允許使用下面的標(biāo)識(shí)
feat:新增功能(feature) fix:修補(bǔ)bug docs:僅僅修改了文檔,比如 README, CHANGELOG, CONTRIBUTE等等 style: 僅僅修改了空格、格式縮進(jìn)、逗號(hào)等等,不改變代碼邏輯 refactor:重構(gòu)(即不是新增功能,也不是修改bug的代碼變動(dòng)) test:增加測(cè)試,包括單元測(cè)試、集成測(cè)試等 chore:構(gòu)建過(guò)程或輔助工具的變動(dòng) type:代表某次提交的類型,比如是修復(fù)一個(gè)bug還是增加一個(gè)新的feature。 perf: 優(yōu)化相關(guān),比如提升性能、體驗(yàn) revert: 回滾到上一個(gè)版本 ci:自動(dòng)化流程配置修改
注:如果type為feat和fix,則該 commit 將肯定出現(xiàn)在 Change log 之中
(2)scope
scope用于說(shuō)明 commit 影響的范圍,比如數(shù)據(jù)層、控制層、視圖層等等,視項(xiàng)目不同而不同。
(3)subject
①subject是 commit 目的的簡(jiǎn)短描述,不超過(guò)50個(gè)字符。 ②以動(dòng)詞開(kāi)頭,使用第一人稱現(xiàn)在時(shí),比如change,而不是changed或changes ③第一個(gè)字母小寫 ④結(jié)尾不加句號(hào)(.)
二、Body
Body 部分是對(duì)本次 commit 的詳細(xì)描述,可以分成多行
三、Footer
Footer 部分只用于兩種情況:
(1)不兼容變動(dòng)
如果當(dāng)前代碼與上一個(gè)版本不兼容,則 Footer 部分以BREAKING CHANGE開(kāi)頭,后面是對(duì)變動(dòng)的描述、以及變動(dòng)理由和遷移方法
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below: Before: scope: { myAttr: "attribute", } After: scope: { myAttr: "@", } The removed `inject` wasn"t generaly useful for directives so there should be no code using it.
(2)關(guān)閉 Issue
如果當(dāng)前 commit 針對(duì)某個(gè)issue,那么可以在 Footer 部分關(guān)閉這個(gè) issue Closes #234 也可以一次關(guān)閉多個(gè) issue Closes #123, #245, #992
四、Revert
如果當(dāng)前 commit 用于撤銷以前的 commit,則必須以revert:開(kāi)頭,后面跟著被撤銷 Commit 的 Header revert: feat(pencil): add "graphiteWidth" option This reverts commit 667ecc1654a317a13331b17617d973392f415f02. ①Body部分的格式是固定的,必須寫成This reverts commit .,其中的hash是被撤銷 commit 的 SHA 標(biāo)識(shí)符。 ②如果當(dāng)前 commit 與被撤銷的 commit,在同一個(gè)發(fā)布(release)里面,那么它們都不會(huì)出現(xiàn)在 Change log 里面。如果兩者在不同的發(fā)布,那么當(dāng)前 commit,會(huì)出現(xiàn)在 Change log 的Reverts小標(biāo)題下面。 commit message工具 Commitizen是一個(gè)格式化commit message的工具。
**
使用
**
1.在cmd中通過(guò)npm來(lái)全局安裝:
npm install -g commitizen
2.在項(xiàng)目目錄下創(chuàng)建package.json文件
npm init
3.打開(kāi)項(xiàng)目執(zhí)行如下命令:
commitizen init cz-conventional-changelog --save --save-exact
注意:如果是第二次配置,需要用–force:
commitizen init cz-conventional-changelog --save --force
4.將未暫存文件所有變化提交到暫存區(qū)
git add .
① git add . :他會(huì)監(jiān)控工作區(qū)的狀態(tài)樹(shù),使用它會(huì)把工作時(shí)的所有變化提交到暫存區(qū),包括文件內(nèi)容修改(modified)以及新文件(new),但不包括被刪除的文件。
②git add -u :他僅監(jiān)控已經(jīng)被add的文件(即tracked file),他會(huì)將被修改的文件提交到暫存區(qū)(git add --update的縮寫)。add -u 不會(huì)提交新文件。
③git add -a :是上面兩個(gè)功能的合集(git add --all的縮寫)
5.命令行輸入提交命令
git cz
輸入命令后依次提示:
①上、下鍵選擇要提交的更改類型 ②此更改的范圍是什么(例如組件或文件名)?(按回車鍵跳過(guò)) ③寫一個(gè)簡(jiǎn)短的祈使句來(lái)描述這個(gè)變化 ④提供更詳細(xì)的更改說(shuō)明:(按回車鍵跳過(guò)) ⑤有什么重大變化嗎? ⑥這一變化是否會(huì)影響 任何未解決的問(wèn)題? 6.再推送到本地git倉(cāng)庫(kù)
git push 注意: ① 代碼需要提測(cè),并且自己都測(cè)試OK了,如果一次性測(cè)試通過(guò)則可以把master合并到自己的分支,然后push自己的分支,進(jìn)行提測(cè) ② 代碼提測(cè)了,如果有問(wèn)題,把問(wèn)題修改好后,再push自己的分支
打印日志命令
git log
1.輸出CHANGELOG記錄,(文件名稱自己設(shè)置),通過(guò)以下命令,在項(xiàng)目中生成 CHANGELOG.md 文件
①安裝生成 Change log 的工具
$ npm install -g conventional-changelog-cli
② 通過(guò)提交記錄生成 CHANGELOG.md
$ conventional-changelog -p -i CHANGELOG.md -s
2.打印出 git log 的日志記錄(詳細(xì)日志記錄)
git log > 文件名
例如:git log >1.txt
在該項(xiàng)目路徑中可查看 1.txt 日志記錄文件
type類型可自行配置
type是可以自己配置和修改的,在項(xiàng)目路徑下的
node_modulesconventional-commit-typesindex.json文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/74988.html
摘要:代碼提交規(guī)范前言在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及處理時(shí)會(huì)更加方便。每次提交代碼,都要寫提交說(shuō)明,否則就不允許提交。一般來(lái)說(shuō),應(yīng)該清晰明了,說(shuō)明本次提交的目的。不會(huì)提交新文件。 Commit message 代碼提交規(guī)范**前言**在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一、代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及Bug處理時(shí)會(huì)更加方便。Git 每次...
摘要:代碼提交規(guī)范前言在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及處理時(shí)會(huì)更加方便。每次提交代碼,都要寫提交說(shuō)明,否則就不允許提交。一般來(lái)說(shuō),應(yīng)該清晰明了,說(shuō)明本次提交的目的。不會(huì)提交新文件。 Commit message 代碼提交規(guī)范**前言**在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一、代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及Bug處理時(shí)會(huì)更加方便。Git 每次...
摘要:代碼提交規(guī)范前言在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及處理時(shí)會(huì)更加方便。每次提交代碼,都要寫提交說(shuō)明,否則就不允許提交。一般來(lái)說(shuō),應(yīng)該清晰明了,說(shuō)明本次提交的目的。不會(huì)提交新文件。 Commit message 代碼提交規(guī)范**前言**在多人協(xié)作項(xiàng)目中,如果代碼風(fēng)格統(tǒng)一、代碼提交信息的說(shuō)明準(zhǔn)確,那么在后期協(xié)作以及Bug處理時(shí)會(huì)更加方便。Git 每次...
摘要:既然是實(shí)戰(zhàn)項(xiàng)目,我們也得在寫頁(yè)面之前把相關(guān)的規(guī)范配置做好。使用來(lái)執(zhí)行規(guī)范全局安裝下需在前面加項(xiàng)目目錄下執(zhí)行配好后,之后用到命令時(shí),改為使用。使用效驗(yàn)提交信息首先還是安裝依賴也會(huì)安裝但自且并不和之后的版本兼容。 生活不能隨意過(guò),代碼也不能隨意寫。 前一篇文章我們已經(jīng)把項(xiàng)目搭建好了,那是不是馬上就開(kāi)始寫頁(yè)面了呀? NO! 無(wú)論在哪家公司,都會(huì)有相應(yīng)的代碼規(guī)范。新入職的員工往往第一步就要接受...
閱讀 2154·2021-10-12 10:11
閱讀 851·2021-10-09 09:41
閱讀 3773·2021-09-09 11:37
閱讀 1950·2021-09-08 10:41
閱讀 2647·2019-08-30 12:58
閱讀 2376·2019-08-30 10:58
閱讀 1286·2019-08-26 13:40
閱讀 4125·2019-08-26 13:36