你見過最奇葩的代碼提交信息是什麼？別再爲寫commit message頭疼了！
寫在前面
對一個developer來講，有時候變量命名，提交代碼時的提交信息會讓人很頭疼，本文主要聊聊怎麼優雅的書寫commit message。前端
你見過最奇葩的代碼提交信息是什麼？
曾在上家公司的一個項目中，見過我至今以來見過最奇葩的代碼提交信息，讓我至今難忘。那個項目的前三個commit記錄的提交信息分別是：git
First Blood
Double kill
Triple kill
複製代碼
簡直讓人哭笑不得，不知道那位仁兄是否是在一邊寫代碼一邊開黑。你是否也見過什麼樣的奇葩的commit message呢？！github
這樣的提交信息，不只沒法告知其餘人以前提交了什麼內容，並且會讓以爲很不認真很不專業。npm
那規範的commitmessage能給咱們帶來哪些好處呢？json
規範commit message的好處
-
可讀性好，根據commit信息就能明確知道本次提交的修改內容及影響範圍bash
-
能夠根據不一樣的提交類型，過濾掉不想關注的提交，提升效率app
-
能夠自動化生成changeLog，甚至能夠自動更新語義話的版本框架
-
能夠下降codereview的溝通成本electron
-
一份清晰規範的commit messge，可讓你表現的更專業工具
那麼什麼樣的commit message纔算是好的呢？咱們來看看在業界被不少人認同的兩種提交風格。
Angular規範
Angular 的commit信息由標題，正文和頁腳三個部分組成，每一個部分中間經過空行分隔。標題部分包括類型，範圍和主題三個部分。
<type>(<scope>): <subject><BLANK LINE>
<body>
<BLANK LINE><footer>
複製代碼
type 提交類型
提交的類型必須是下面的一個：
feat：增長一個新功能
fix：修復bug
docs：只修改了文檔
style：作了不影響代碼含義的修改，空格、格式化、缺乏分號等等
refactor：進行代碼重構，既不是修復bug，也不是新功能的修改
perf：改進性能的代碼
test：增長測試或更新已有的測試
chore：構建或輔助工具或依賴庫的更新
scope 範圍
說明當前提交的代碼影響的範圍，若是當前更改影響的不止一個範圍時，可使用*
subject 描述
包含對變動的簡潔描述: 使用祈使句，如今時態:"change"而不是"changed"或"changes"，第一個字母不要大寫, 末尾沒有點(.)
body 正文
使用祈使句，body應該包括爲何修改，具體修改了哪些了東西。
footer 頁腳註釋
用來放置 Breaking Changes 或 Closed Issues
Conventional Commits 規範
基於Angular的提交規範衍生出的規範，很大程度上以其爲Augular的規範爲依據 提交格式與Augular基本一致
<type>[optional scope]: <description>
[optional body]
[optional footer]
複製代碼
type 提交類型
類型是必須提供的，且必須是名詞，其後接一個可選的做用域字段，以及一個必要的冒號（英文半角）和空格；
- 提交新功能或新特性時，必須使用feat類型；
- 修復了 bug 時，必須使用fix類型；
- 可使用 feat 和 fix 以外的類型;
scope 範圍
做用域必須是一個描述某部分代碼的名詞，並使用圓括號
description 描述
描述是必須項，字段必須緊接在類型/做用域的空格以後。描述指的是對代碼變動的簡短總結
body 正文
正文可可選的，若是書寫必須起始於描述字段結束的一個空行後
footer
正文結束的一個空行以後，能夠編寫一行或多行腳註
BREAKING CHANGE
不兼容更新必須標示在正文區域最開始，或腳註區域中某一行的開始，必須包含大寫的文本BREAKING CHANGE，後面緊跟冒號和空格。
在 BREAKING CHANGE: 以後必須提供描述，以描述對 API 的變動。例如：BREAKING CHANGE: environment variables now take precedence over config files.
能夠在類型/做用域前綴以後，: 以前，附加 ! 字符，以進一步提醒注意不兼容變動。當有 ! 前綴時，正文或腳註內必須包含 BREAKING CHANGE: description
Conventional Commits規範是和SemVer規範（語義化版本）的約定是吻合的。
SemVer 是一套語義化版本控制的約定，定義的格式爲 ** X.Y.Z（主版本號.次版本號.修訂號）** ：
X.主版本號：進行不向下兼容的修改時，遞增主版本號
Y.次版本號: 作了向下兼容的新增功能或修改
Z.修訂號：作了向下兼容的問題修復
Conventional Commits規範是和SemVer規範相吻合的目的是什麼呢？！ 咱們能夠根據commit的類型去自動化的生成語義化的版本。
咱們比較熟知 electron 項目就採用了Conventional Commits規範，其餘採用了這套規範的開源項目還有：
- yargs：廣受歡迎的命令行參數解析器。
- istanbuljs：一套爲 JavaScript 測試生成測試覆蓋率的開源工具和類庫。
- uPortal-home 和 uPortal-application-framework：用於加強 Apereo uPortal 的可選用戶界面。
- massive.js：一個用於 Node 和 PostgreSQL 的數據訪問類庫。
- scroll-utility：一個居中元素和平滑動畫的滾屏工具包實例。
- Blaze UI：無框架開源 UI 套件。
- Monica：一個開源的人際關係管理系統。
相關工具
有了規範是好事，但不想記那麼多的type怎麼辦？又怎麼保證團隊每一個成員真的按照規範去執行呢？這些均可以經過工具來解決。
Commitizen
一款幫助咱們按照規則去提交提交代碼的懶人工具，它是一個通用的工具，提供了多種commit Message風格能夠選擇，好比咱們上面提到的Conventional規範，就能夠經過按照 cz-conventional-changelog 來實現。
除了提供了一些可選的風格，還支持根據已有的規範去更改建立一套屬於本身團隊的風格配置。
安裝：
npm install commitizen -g
複製代碼
選擇風格：
commitizen init cz-conventional-changelog --save-dev --save-exact
複製代碼
or
commitizen init cz-conventional-changelog --yarn --dev --exact
複製代碼
提交代碼時，使用git cz 代替 git commit，每一步都會有提示，保證按照規範提交。
commitlint
commit message 的 linter，用來對 message 進行檢查，防止提交了不符合規範的提交信息。
能夠結合 git hooks 在提交commit時進行自動檢查，不符合規範的commit不容許提交。
一樣的，commitlint也支持配置安裝不一樣風格的配置，同時，你也可以發佈並使用本身的配置。
安裝：
npm install --save-dev @commitlint/{config-conventional,cli}
複製代碼
配置風格
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
複製代碼
結合git hooks使用
先安裝husky
npm install --save-dev husky
複製代碼
package.json中增長配置
{
"husky":{
"hooks": {"commit-msg": "commitlint -E HUSKY_GIT_PARAMS" }
}
}
複製代碼
這樣在輸入不符合風格的commit Message會沒法經過，並會給出具體的提示。
standard-version
standard-version須要使用Conventional Commits規範，可以幫助自動生成符合SemVer規範的版本和 CHANGELOG。
安裝：
npm i --save-dev standard-version
複製代碼
package.json中增長配置：
{"scripts": {"release": "standard-version" }}
複製代碼
第一次發佈版本，執行命令，同時生成changeLog
npm run release -- --first-release
複製代碼
以後版本變動，直接執行
npm run release
複製代碼
常見問題
一次提交多種類型怎麼操做
儘量拆分的task，每完成一部分就進行一次提交，避免一次提交過多的代碼。這樣可以避免一次commit修改過多文件，致使後續的維護，回退等的困難。
若是真的有這樣的提交，能夠選擇最重要改動的type，在body部分詳細寫明具體的改動。
提交了不規範的信息怎麼處理
若是使用了Commitizen或commitlint，基本上能夠保證提交符合規範的Message，可是也可能出現選錯了類型的問題，好比是新增的功能，可是一手抖，選成了fix並完成了commit，這時可使用 git rebase -i 來編輯提交歷史。
參考
Angular規範：github.com/angular/ang…
Conventional Commits 規範： www.conventionalcommits.org/en/v1.0.0-b…
SemVer規範： semver.org/
歡迎關注個人公衆號「前端小苑」，我會按期在上面更新原創文章。
- 1. 作爲一個技術人員，你見過產品提出的最奇葩需求是什麼?
- 2. 做爲程序員都碰見過什麼奇葩? 客戶: 你有病？代碼寫這麼多註釋！
- 3. Commit message 代碼提交規範
- 4. 優雅的提交你的 Git Commit Message
- 5. 你見過最爛的 Java 代碼是什麼？
- 6. 【譯】求你不要再寫沒用的提交信息了
- 7. 程序員：你見過哪些要命的奇葩代碼？
- 8. 我是怎麼寫 Git Commit message 的？
- 9. 寫代碼什麼是最重要的？
- 10. Vuex- Action的 { commit } {commit}是什麼寫法
- 更多相關文章...
- • HTTP 響應頭信息 - HTTP 教程
- • Hibernate是什麼 - Hibernate教程
- • 再有人問你分佈式事務，把這篇扔給他
- • IntelliJ IDEA代碼格式化設置
-
每一个你不满意的现在，都有一个你没有努力的曾经。