1. 前言

目前大部分公司都在使用 Git 作爲版本控制，每個程序員每天都要進行代碼的提交。很多開發者也包括我自己，有時候趕時間或者圖省事，就這麼提交：

過了一段，突然去查找一個具體的提交你會發現不是特別好找。因此我們需要規範我們的代碼提交來避免這種情況。同時良好的提交規範也有助於我們生成清晰的 ChangeLog，更利於同事之間的協作。

如果你想成爲知名開源項目的貢獻者更要規範自己的代碼提交。

2. Git 提交規範

目前業內做的比較好的，比較具有參考價值的就是知名前端框架

AngularJS

的提交規範。我們先來看一個例子：

Git提交信息

對應的格式：

更嚴格的項目可能提交要求使用英文描述，特別是國際化的開源項目。

根據上面這個例子我們來了解一下這個業界比較認可的 Git 提交規範。

type

表示本次提交的是

重構

代碼，也就是它是一個提交的類型，除了還有：

新功能，顧名思義就是新需求的實現。

修復，就是對 bug 的修復。

文檔，主要用來描述文檔的變更。

主要是代碼風格相關的提交，比如格式化等。

重構代碼，對已有功能的重構，但是區別於 bugfix。

測試相關的提交，不太常用。

構建過程或輔助工具的變動，不太常用，比如之前用 Maven，後面換成了 Gradle。

每次提交聲明提交的是必須的，它讓本次提交的作用一目瞭然。

scope（可選）

用來表明本次提交影響的範圍，方便快速定位。你可以寫明影響的是哪個模塊（通常是模塊名稱）或者是哪個層（數據層、服務層、還是視圖層）。

subject

就是上面的，是對本次提交的簡短描述概括。就像胖哥寫文章要起一個標題一樣，不要過長。

body（可選）

就是比較詳細描述本次提交涉及的條目，羅列代碼功能，這裏胖哥習慣用

markdown

的列表語法，也就是用中劃線換行隔開條目。當然不是必選的，如果能夠描述清楚的話。

foot（可選）

描述與本次提交相關聯的

break change

或

issue

。

break change

指明本次提交是否產生了破壞性修改，類似版本升級、接口參數減少、接口刪除、遷移等。如果產生了上述的影響強烈建議在提交信息中寫明

break change

，有利於出問題時快速定位，回滾，覆盤。

issue

如果發現項目有 bug、或者有優化的建議、甚至新增一個任務，就可以利用

issue

給項目提交一個任務。

Git issue

issue

不是一些 Git 平臺的專屬功能，JIRA 等平臺也有類似功能，它們的作用大同小異，都可以很好地反應項目的成長狀況和參與度。那麼在 Git 提交時，我們可以在

foot

區域關聯本次提交涉及的

issue

。

這裏沒有固定格式，不過儘量去參考一些知名項目去做。

3. 工具安利

說了這麼多，相信你已經對 Git 提交的規範有所瞭解了。這裏推薦一些有用的工具來幫助你將這些規範落實到位。在

Intellij IDEA

的插件市場有很多 Git Commit Message 模板插件，可以可視化的實現這些規範。

Git提交信息插件

Lambda在Java開發中的實際運用經驗分享

2021-01-20

微信支付V3實現Payment Spring Boot 1.0.4.RELEASE發佈，支持商家券

2021-01-18

JSON轉Java POJO就是這麼簡單快捷

2021-01-16