建站
咨詢
售后
建站咨詢
新聞中心
Git 相信大家在日常的工作中經常會使用到，在我們完成一個需求開發(fā)或者 bug 修復的時候都會將變動的代碼文件進行 commit 提交到遠程。
從事服務器托管，服務器租用，云主機，網絡空間，空間域名，CDN，網絡代維等服務。
那么問題來了，仔細看下你的提交記錄，里面是不是有很多 test ，fix，update，add 等等絲毫看不出任何含義的 commit message。
commit message 的提交很多時候都只依賴開發(fā)人員的自我規(guī)范，而開發(fā)人員往往在需求緊急或者 bug 要及時修復的時候，根本不會花很多時間在寫 git commit message 的信息。而且就算是寫，每個人的風格也不一樣，所以寫出來的 message 也不完全相同。
這個時候我們就需要有一套規(guī)范了，現(xiàn)在業(yè)界比較常用的規(guī)范是的格式是這樣的：type(scope):subject，下面我們詳細來聊一下。
Type
type 代表的是提交內容的一種類型，每一種類型都代表著不同的含義，具體的類型取值和含義如下：
- feat：表示開發(fā)一個新的需求特性；
- fix：表示修復一個 bug；
- docs：表示是針對文檔的修改，并沒有修改代碼；
- style：格式修改，不影響代碼功能；
- refactor：不是進行 feat 和 fix 的代碼修改，重構功能；
- perf：提升性能的代碼修改；
- test：添加測試代碼或者修正已經存在的測試功能代碼；
- build：修改會影響構建或者依賴的代碼；
- ci：修改集成配置的文件或者腳本；
- chore：一些不夠影響到源碼和測試文件的修改；
- revert：針對之前的一個提交的 revert 修改；
對于我們來說在寫一個 git commit 的時候，要搞清楚當前提交的內容的真正含義是什么，從而選擇正確的類型。此外還要求我們對于代碼的修改需要盡量細粒度，話句話說就是盡量將一個大的改動進行拆分，根據適當的情況進行 git 提交，避免一次性提交太多的改動。
Scope
scope 表示的當次 git 提交的內容影響的范圍，這個范圍比較寬泛，比如可以是 DAO 層，Controller 層，或者是具有特定功能的比如 utils 工具模塊，權限模塊，數據模塊等等，只要能跟自己的項目掛上鉤，表達出修改的范圍就行，如果涉及到的范圍比較多的話，可以用 * 表示，并不強制要求。
Subject
subject 部分是最重要的 git commit message 的部分，也就是我們經常要寫提交信息的部分，這一部分通常會一個言簡意賅的信息描述，需要寫出我們改動代碼的原因。
上面的 type，scope，subject 三個部分是我們常用的部分，不過有些規(guī)范將 git 的提交規(guī)范定義為 Header，Body 和 Footer 三個部分，而 type，scope，subject 三個屬于 Header 的部分。
擴展
Header 部分也就是上面提到的三個部分，是每個 git 提交的基礎內容；Body 部分則是更加詳細的描述信息，用于完整記錄代碼的修改地方和邏輯；Footer 部分則會將本次提交的內容與具體的需求或者缺陷相關聯(lián)，比如對應的需求地址是什么，或者修復的 Bug 缺陷是什么等。
IDEA 插件
上面的內容不多，但是要記下來的還是很繁瑣的，特別是有時候我們很難記住所有的 type 類型，好在 IDEA 現(xiàn)在有一個插件，就是用來規(guī)范 git 提交模板的。
在 IDEA 的插件市場中安裝 git commit template，直接搜索安裝，然后重啟 IDEA 即可。
圖片
安裝完成過后，在我們需求提交代碼的時候，會出現(xiàn)這個按鈕。
圖片
點擊一下就可以看到下面這個頁面，其中 short description 就是我們上面提到的 subject，而 Long description 代表的就是 Body 部分，而下面的 Breaking changes 和 Closed issues 則代表的是 Footer 部分，在使用的過程中按需填入即可。
圖片
總結
有很多小伙伴就要問了，寫那么詳細有什么用？規(guī)范我們的提交記錄，主要是為了能追溯代碼歷史，很多時候我們自己寫的代碼在時間長了以后都記不住，更不要說別人寫的代碼了，所以只能從流程和規(guī)范上面來幫助大家更好的記憶。
網站題目：程序員如何通過插件規(guī)范Gitcommitmessage的提交？
文章來源：http://www.dlmjj.cn/article/djoegsg.html
