前言
程式設計師在開發完代碼後都需要向代碼倉庫提交代碼,通常我們會使用下面的Git命令
git commit -m '此次代碼的說明'
但是很多時候我們都沒有一個統一的約定去規範commit描述,這就導致提交的歷史信息不能被很好查閱而且也不容易辨認commit信息與代碼變動之間的聯繫。
這篇文章我們聊一下Augular提交規範。
工具——commitizen
首先我們全局安裝一下commitizen,
npm install commitizen -g
下一步建一個github倉庫做測試,首先在倉庫中執行如下命令,
npm init
上面的命令不能跳過,然後再在倉庫中運行下面的命令,
commitizen init cz-conventional-changelog --save-dev --save-exact
如果你用yarn,也可以用下面的命令
commitizen init cz-conventional-changelog --yarn --dev --exact
上面的命令為你做了三件事
(1)安裝cz-conventional-changelog適配npm module;
(2)將cz-conventional-changelog保存在了package.json的dependencies或者devDependencies中;
(3)在package.json中添加了一個配置,如下:
圖2中的配置主要是為了告訴Commitizen當開發者向倉庫提交代碼時使用哪一個適配器。
commitizen.path主要通過require.resolve解析路徑,它支持以下幾種路徑寫法,
(1)npm包;
(2)包含index.js文件的文件夾,文件夾路徑相對命令執行目錄;
(3)js文件,文件路徑相對命令執行目錄;
(4)完全相對路徑;
(5)絕對路徑。
完成以上工作,我們來嘗試提交一下代碼,提交代碼時需要把git commit命令替換成git cz,看看會發生什麼?
如圖3,git cz命令直接彈出了一個交互選項,我們來看看都代表什麼意思?
(1)feat代表新功能;
(2)fix代表修復bug;
(3)docs代表修復文檔;
(4)style代表代碼格式變化;
(5)refactor代表代碼重構;
(6)perf代表性能優化;
(7)test代表修改或者增加測試;
(8)revert代表回退到之前的一個commit;
(9)build代表對構建流的修改;
(10)ci代表ci的一些配置還有一些腳本的修改;
(11)chore代表非原始碼src和測試文件的修改。
Commitizen為我們羅列了11種提交場景,非常的細,換句話說咱們後面不能把所有的代碼修改都放在一個commit中,需要按照以上場景逐次提交。
下面我們繼續操作!
如圖4,Commitizen除了會詢問你的提交類型,還會讓你告知它其他信息,
(1)本次修改的範圍,可以填寫組件名字或者文件名,也可以直接跳過;
(2)寫一個簡短的描述,主要是在github的code tab下展示;
(3)寫一個詳細的修改描述;
(4)詢問開發者有沒有重大修改;
(5)如果有重大修改,描述一下;沒有就跳過;
(6)詢問本次修改是否影響打開中的issue;
(7)如果影響issue,可以寫fix #123,closes #123 等等。
完成這些信息填寫,就可以把代碼提交上去了,效果如下:
到目前為止,我們成功使用Commitizen完成了代碼的提交。步驟很簡單,而且每一步Commitizen都會有提示,很貼心,如果你英文不是太差,基本都能看的懂。
總結
從以上介紹可以看出Commitizen將代碼提交的場景劃分的很細,而且規範了提交的描述。對於多人開發的倉庫,可以做到格式統一,好處不言而喻。下篇文章我們接著介紹Commitizen的其他功能。
喜歡我的文章就關注我吧,有問題可以發表評論,我們一起學習,共同成長!