前言
在之前的一篇文章《 》中,我們有講過git status和git diff相關的內容。
今天這篇文章我們看看commit message相關的內容。
概述
在我們使用git commit -m命令提交信息時,在-m參數後面跟的字符串就是commit message,本質上是可以沒有任何格式的。
但是為了團隊協作,為了更好的代碼管理和錯誤排查,我們需要給提交信息設置一定的格式,表明本次提交的目的。
下圖是一個正確的commit message格式。
格式化填寫commit message有以下幾個明顯的好處。
提供更多可查詢的信息,用於瀏覽和排查問題
我們都知道git log是用於查看提交歷史的,當我們需要很明顯的看到提交信息時,可以使用如下命令。
git log --pretty=oneline
過濾重要的內容
在眾多提交中,如果我們只對其中某些commit感興趣,比如fix bug的提交,那麼我們可以通過以下命令去查看。
git log --pretty=oneline --grep fix
可以生成change log
什麼是change log呢?
在很多github倉庫的README中,都會有一部分表示版本更迭的內容,這些就是change log。
如果我們在提交信息時都遵循了commit message規則的是,可以直接通過命令行去生成change log,而不用自己手寫這個文件。
我們可以看看vue的官方change log的一部分,下圖是v2.5.10版本更新時發佈的change log,主要解決一些bug,同時提供源碼下載。
commit messag的格式
標準的commit message是包含Header,Body和Footer三個部分。但是一般不會去填寫這麼多信息。
作為正常開發的話,只需要使用Header部分即可,Body和Footer部分我們就不做闡述。
Header的內容主要分為三個部分,包括type,scope和subject。
type
type主要是用於說明提交的類型,目前常用的是下面7個。
feat:新增加的功能(feature),比如組件庫中新增一個組件。
fix:修復bug,最常見的是解決QA提出的bug。
docs:文檔(documentation),比如對項目README文件的修改。
style: 格式(代碼空行,縮進等格式化,不影響代碼運行的變動)。
refactor:重構(即不是新增功能,也不是修改bug的代碼變動)。
test:增加測試,一般用於增加單元測試。
chore:構建過程或輔助工具的變動,一般是項目版本的變更。
如果我們提交的類型為feat或者fix,則在生成change log時,會自動的追加到change log中;其他類型則是根據指令選擇要不要添加至change log中,建議是不要。
scope
scope用於表示此次提交的影響範圍,根據項目而定。如果是業務項目的話,一般會是業務模塊名;如果是基礎庫類型的項目,一般會是某個底層基礎的內容。
subject
subject用於簡要描述此次提交的內容,一般不超過50個字符。
那麼一個Header完整內容可以展示如下。
commitizen
如果有的時候我們會忘記commit message格式的話,可以通過一個工具來幫助我們實現,這個工具就是commitizen。
使用的方法也很簡單,這裡給大家介紹下。
安裝
通過npm安裝commitizen包,如果只需要在當前倉庫使用默認安裝就可以了,如果需要全局使用則加上-g選項,這裡我們只對當前倉庫使用。
npm install commitizen
初始化配置
在項目倉庫下運行以下命令,支持Angular的Commit Message格式。
運行
當配置完成後,對於以後需要git commit的地方都採用git cz來代替。
需要注意的一點是如果暫存區裡沒有修改的文件,直接去運行git cz會報錯拋出異常,錯誤信息顯示:沒有添加進暫存區的文件。
如果按照正常的流程,git add後,再去運行git cz,則會出現如下提示選項。
我們一般只需要選擇前三項,分別對應Header的style,scope和subject三個部分。
後面的兩個部分不用填寫,直接按回車就行了。這時一條完整的Commit Message就生成了。
我們可以通過git log去查看剛剛生成的Commit Message。
結束語
今天這篇文章主要講解的是commit message相關的內容,只有在大家開發的時候提供了標準的commit message,才能更有助於團隊協同開發和排查問題。
閱讀更多 coder分享 的文章