最近面試 有人問到 你帶了一個團隊 當你離開 留下了什麼 回想一下 感覺做了很多 但 卻無從下口 感覺標準化了很多 但其實 和大廠看來 差距還是太大了 所以 學習之路就在腳下 學吧
今天聊聊 commit message標準化 我一直覺得 認真編寫 message 就是很嚴格的要求 但其實 大廠來說 哪怕 message 都要遵循標準的格式 其實可以理解 畢竟標準的格式 就可以演變出 很多優化後的結果
目前 市面上 流行的 commit message 格式 就是 angular 提出的 格式
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header 是必需的 也就是 <type>(<scope>): <subject> ，Body 和 Footer 可以省略。
主要說下Header
Header部分只有一行，包括三個字段：type（必需）、scope（可選）和subject（必需）。
（1）type
type用於說明 commit 的類別，只允許使用下面7個標識。
feat：新功能（feature）
fix：修補bug
docs：文檔（documentation）
style： 格式（不影響代碼運行的變動）
refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試
chore：構建過程或輔助工具的變動
如果type爲feat和fix，則該 commit 將肯定出現在 Change log 之中。其他情況（docs、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。
（2）scope
scope用於說明 commit 影響的範圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
（3）subject
subject是 commit 目的的簡短描述，不超過50個字符。
以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
第一個字母小寫
結尾不加句號（.）
其他內容可以 查看 阮一峯 老師的 講解 http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
如果 你去強制 團隊的人 做這個 肯定不好推廣 且 確實浪費時間 那麼 我們使用 插件 去解決這個事吧
Commitizen
指令
// 下載模塊
npm install -g commitizen
// 設置成按照angular規範 編寫commit message
commitizen init cz-conventional-changelog --save --save-exact
剩下操作就可以了
不要再git commit -m '斯蒂芬斯蒂芬森發' 使用 指令 git cz 後 根據控制檯可視化的 提交 message
下面說說 change log
// 下載模塊
npm i -D conventional-changelog-cli
然後 爲了方便 . 我們 在 package.json裏 定義2個script 快捷操作
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
"commit": "git cz"
},
這樣 npm run changelog 就 會在本地 生成 CHANGELOG.md 文件
這樣 npm run commit 就是 按照 angular標準 完成git 的 commit message 操作