資訊專欄INFORMATION COLUMN
摘要：代碼提交規范前言在多人協作項目中，如果代碼風格統一代碼提交信息的說明準確，那么在后期協作以及處理時會更加方便。每次提交代碼，都要寫提交說明，否則就不允許提交。一般來說，應該清晰明了，說明本次提交的目的。不會提交新文件。
Commit message 代碼提交規范
**
前言
**
在多人協作項目中，如果代碼風格統一、代碼提交信息的說明準確，那么在后期協作以及Bug處理時會更加方便。Git 每次提交代碼，都要寫 Commit message（提交說明），否則就不允許提交。一般來說，commit message 應該清晰明了，說明本次提交的目的。
Commit message 的作用
● 提供更多的歷史信息，方便快速瀏覽
● 過濾某些commit（比如文檔改動），便于快速查找信息
● 直接從commit生成Change log
● 可讀性好，清晰，不必深入看代碼即可了解當前commit的作用。
● 為 Code Reviewing（代碼審查）做準備
● 方便跟蹤工程歷史
● 提高項目的整體質量，提高個人工程素質
Commit message 的格式
Commit message 包括三個部分：Header，Body 和 Footer
( ): // 空一行 // 空一行
一、Header
Header部分只有一行，包括三個字段：type（必需）、scope（可選）和subject（必需）
（1）type
? type用于說明 commit 的類別，只允許使用下面的標識
feat：新增功能（feature）
fix：修補bug
docs：僅僅修改了文檔，比如 README, CHANGELOG, CONTRIBUTE等等
style： 僅僅修改了空格、格式縮進、逗號等等，不改變代碼邏輯
refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試，包括單元測試、集成測試等
chore：構建過程或輔助工具的變動
type：代表某次提交的類型，比如是修復一個bug還是增加一個新的feature。
perf: 優化相關，比如提升性能、體驗
revert: 回滾到上一個版本
ci：自動化流程配置修改
注：如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中
（2）scope
scope用于說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
（3）subject
①subject是 commit 目的的簡短描述，不超過50個字符。 ②以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes ③第一個字母小寫 ④結尾不加句號（.）
二、Body
Body 部分是對本次 commit 的詳細描述，可以分成多行
三、Footer
Footer 部分只用于兩種情況：
（1）不兼容變動
如果當前代碼與上一個版本不兼容，則 Footer 部分以BREAKING CHANGE開頭，后面是對變動的描述、以及變動理由和遷移方法
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）關閉 Issue
如果當前 commit 針對某個issue，那么可以在 Footer 部分關閉這個 issue Closes #234 也可以一次關閉多個 issue Closes #123, #245, #992
四、Revert
如果當前 commit 用于撤銷以前的 commit，則必須以revert:開頭，后面跟著被撤銷 Commit 的 Header revert: feat(pencil): add "graphiteWidth" option This reverts commit 667ecc1654a317a13331b17617d973392f415f02. ①Body部分的格式是固定的，必須寫成This reverts commit .，其中的hash是被撤銷 commit 的 SHA 標識符。 ②如果當前 commit 與被撤銷的 commit，在同一個發布（release）里面，那么它們都不會出現在 Change log 里面。如果兩者在不同的發布，那么當前 commit，會出現在 Change log 的Reverts小標題下面。 commit message工具 Commitizen是一個格式化commit message的工具。
**
使用
**
1.在cmd中通過npm來全局安裝：
npm install -g commitizen
2.在項目目錄下創建package.json文件
npm init
3.打開項目執行如下命令:
commitizen init cz-conventional-changelog --save --save-exact
注意：如果是第二次配置，需要用–force：
commitizen init cz-conventional-changelog --save --force
4.將未暫存文件所有變化提交到暫存區
git add .
① git add . ：他會監控工作區的狀態樹，使用它會把工作時的所有變化提交到暫存區，包括文件內容修改(modified)以及新文件(new)，但不包括被刪除的文件。
②git add -u ：他僅監控已經被add的文件（即tracked file），他會將被修改的文件提交到暫存區（git add --update的縮寫）。add -u 不會提交新文件。
③git add -a ：是上面兩個功能的合集（git add --all的縮寫）
5.命令行輸入提交命令
git cz
輸入命令后依次提示：
①上、下鍵選擇要提交的更改類型 ②此更改的范圍是什么(例如組件或文件名)?(按回車鍵跳過) ③寫一個簡短的祈使句來描述這個變化 ④提供更詳細的更改說明:(按回車鍵跳過) ⑤有什么重大變化嗎? ⑥這一變化是否會影響 任何未解決的問題? 6.再推送到本地git倉庫
git push
注意：
① 代碼需要提測，并且自己都測試OK了，如果一次性測試通過則可以把master合并到自己的分支，然后push自己的分支，進行提測
② 代碼提測了，如果有問題，把問題修改好后，再push自己的分支
打印日志命令
git log
1.輸出CHANGELOG記錄，（文件名稱自己設置），通過以下命令，在項目中生成 CHANGELOG.md 文件
①安裝生成 Change log 的工具
$ npm install -g conventional-changelog-cli
② 通過提交記錄生成 CHANGELOG.md
$ conventional-changelog -p -i CHANGELOG.md -s
2.打印出 git log 的日志記錄（詳細日志記錄）
git log > 文件名
例如：git log >1.txt
在該項目路徑中可查看 1.txt 日志記錄文件
type類型可自行配置
type是可以自己配置和修改的，在項目路徑下的
node_modulesconventional-commit-typesindex.json文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/114881.html
摘要：代碼提交規范前言在多人協作項目中，如果代碼風格統一代碼提交信息的說明準確，那么在后期協作以及處理時會更加方便。每次提交代碼，都要寫提交說明，否則就不允許提交。一般來說，應該清晰明了，說明本次提交的目的。不會提交新文件。 Commit message 代碼提交規范**前言**在多人協作項目中，如果代碼風格統一、代碼提交信息的說明準確，那么在后期協作以及Bug處理時會更加方便。Git 每次...
摘要：代碼提交規范前言在多人協作項目中，如果代碼風格統一代碼提交信息的說明準確，那么在后期協作以及處理時會更加方便。每次提交代碼，都要寫提交說明，否則就不允許提交。一般來說，應該清晰明了，說明本次提交的目的。不會提交新文件。 Commit message 代碼提交規范**前言**在多人協作項目中，如果代碼風格統一、代碼提交信息的說明準確，那么在后期協作以及Bug處理時會更加方便。Git 每次...
摘要：代碼提交規范前言在多人協作項目中，如果代碼風格統一代碼提交信息的說明準確，那么在后期協作以及處理時會更加方便。每次提交代碼，都要寫提交說明，否則就不允許提交。一般來說，應該清晰明了，說明本次提交的目的。不會提交新文件。 Commit message 代碼提交規范**前言**在多人協作項目中，如果代碼風格統一、代碼提交信息的說明準確，那么在后期協作以及Bug處理時會更加方便。Git 每次...
摘要：既然是實戰項目，我們也得在寫頁面之前把相關的規范配置做好。使用來執行規范全局安裝下需在前面加項目目錄下執行配好后，之后用到命令時，改為使用。使用效驗提交信息首先還是安裝依賴也會安裝但自且并不和之后的版本兼容。 生活不能隨意過，代碼也不能隨意寫。 前一篇文章我們已經把項目搭建好了，那是不是馬上就開始寫頁面了呀？ NO！ 無論在哪家公司，都會有相應的代碼規范。新入職的員工往往第一步就要接受...
閱讀 1630·2021-10-27 14:13
閱讀 1868·2021-10-11 10:59
閱讀 3367·2021-09-24 10:26
閱讀 1925·2019-08-30 12:48
閱讀 3041·2019-08-30 12:46
閱讀 2033·2019-08-30 11:16
閱讀 1414·2019-08-30 10:48
閱讀 2740·2019-08-29 16:54
