Git 相信大家在日常的工作中經常會使用到，在我們完成一個需求開發或者 bug 修復的時候都會將變動的代碼文件進行 commit 提交到遠程。

那么問題來了，仔細看下你的提交記錄，里面是不是有很多 test ，fix，update，add 等等絲毫看不出任何含義的 commit message。

commit message 的提交很多時候都只依賴開發人員的自我規范，而開發人員往往在需求緊急或者 bug 要及時修復的時候，根本不會花很多時間在寫 git commit message 的信息。而且就算是寫，每個人的風格也不一樣，所以寫出來的 message 也不完全相同。

這個時候我們就需要有一套規范了，現在業界比較常用的規范是的格式是這樣的：type(scope):subject，下面我們詳細來聊一下。

Type

type 代表的是提交內容的一種類型，每一種類型都代表著不同的含義，具體的類型取值和含義如下：

1. feat：表示開發一個新的需求特性；
2. fix：表示修復一個 bug；
3. docs：表示是針對文檔的修改，并沒有修改代碼；
4. style：格式修改，不影響代碼功能；
5. refactor：不是進行 feat 和 fix 的代碼修改，重構功能；
6. perf：提升性能的代碼修改；
7. test：添加測試代碼或者修正已經存在的測試功能代碼；
8. build：修改會影響構建或者依賴的代碼；
9. ci：修改集成配置的文件或者腳本；
10. chore：一些不夠影響到源碼和測試文件的修改；
11. revert：針對之前的一個提交的 revert 修改；

對于我們來說在寫一個 git commit 的時候，要搞清楚當前提交的內容的真正含義是什么，從而選擇正確的類型。此外還要求我們對于代碼的修改需要盡量細粒度，話句話說就是盡量將一個大的改動進行拆分，根據適當的情況進行 git 提交，避免一次性提交太多的改動。

Scope

scope 表示的當次 git 提交的內容影響的范圍，這個范圍比較寬泛，比如可以是 DAO 層，Controller 層，或者是具有特定功能的比如 utils 工具模塊，權限模塊，數據模塊等等，只要能跟自己的項目掛上鉤，表達出修改的范圍就行，如果涉及到的范圍比較多的話，可以用 * 表示，并不強制要求。

Subject

subject 部分是最重要的 git commit message 的部分，也就是我們經常要寫提交信息的部分，這一部分通常會一個言簡意賅的信息描述，需要寫出我們改動代碼的原因。

上面的 type，scope，subject 三個部分是我們常用的部分，不過有些規范將 git 的提交規范定義為 Header，Body 和 Footer 三個部分，而 type，scope，subject 三個屬于 Header 的部分。

擴展

Header 部分也就是上面提到的三個部分，是每個 git 提交的基礎內容；Body 部分則是更加詳細的描述信息，用于完整記錄代碼的修改地方和邏輯；Footer 部分則會將本次提交的內容與具體的需求或者缺陷相關聯，比如對應的需求地址是什么，或者修復的 Bug 缺陷是什么等。

IDEA 插件

上面的內容不多，但是要記下來的還是很繁瑣的，特別是有時候我們很難記住所有的 type 類型，好在 IDEA 現在有一個插件，就是用來規范 git 提交模板的。

在 IDEA 的插件市場中安裝 git commit template，直接搜索安裝，然后重啟 IDEA 即可。

圖片

安裝完成過后，在我們需求提交代碼的時候，會出現這個按鈕。

圖片

點擊一下就可以看到下面這個頁面，其中 short description 就是我們上面提到的 subject，而 Long description 代表的就是 Body 部分，而下面的 Breaking changes 和 Closed issues 則代表的是 Footer 部分，在使用的過程中按需填入即可。

圖片

總結

有很多小伙伴就要問了，寫那么詳細有什么用？規范我們的提交記錄，主要是為了能追溯代碼歷史，很多時候我們自己寫的代碼在時間長了以后都記不住，更不要說別人寫的代碼了，所以只能從流程和規范上面來幫助大家更好的記憶。