開發中的你的Git提交規範嗎？

1. 前言

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

git commit -m "修改bug,優化代碼"

過了一段，忽然去查找一個具體的提交你會發現不是特別好找。所以咱們須要規範咱們的代碼提交來避免這種狀況。同時良好的提交規範也有助於咱們生成清晰的ChangeLog，更利於同事之間的協做。

若是你想成爲知名開源項目的貢獻者更要規範本身的代碼提交。

2. Git提交規範

目前業內作的比較好的，比較具備參考價值的就是知名前端框架AngularJS的提交規範。咱們先來看一個例子：

對應的格式：

<type>[optional scope]: <description>
# 空行
[optional body]
# 空行
[optional footer]

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

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

type

refactor 表示本次提交的是重構代碼，也就是它是一個提交的類型type，除了refactor還有：

• feat 新功能，顧名思義就是新需求的實現。
• fix 修復，就是對bug的修復。
• docs 文檔，主要用來描述文檔的變動。
• style 主要是代碼風格相關的提交，好比格式化等。
• refactor 重構代碼，對已有功能的重構，可是區別於bugfix。
• test 測試相關的提交，不太經常使用。
• chore 構建過程或輔助工具的變更，不太經常使用，好比以前用Maven，後面換成了Gradle。

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

scope（可選）

用來代表本次提交影響的範圍，方便快速定位。你能夠寫明影響的是哪一個模塊（一般是模塊名稱）或者是哪一個層（數據層、服務層、仍是視圖層）。

subject

就是上面的修改版權信息，是對本次提交的簡短描述歸納。就像胖哥寫文章要起一個標題同樣，不要過長。

body（可選）

就是比較詳細描述本次提交涉及的條目，羅列代碼功能，這裏胖哥習慣用markdown的列表語法，也就是用中劃線換行隔開條目。固然body不是必選的，若是subject可以描述清楚的話。

foot（可選）

描述與本次提交相關聯的break change或issue 。

break change

指明本次提交是否產生了破壞性修改，相似版本升級、接口參數減小、接口刪除、遷移等。若是產生了上述的影響強烈建議在提交信息中寫明break change，有利於出問題時快速定位，回滾，覆盤。

issue

若是發現項目有bug、或者有優化的建議、甚至新增一個任務，就能夠利用issue給項目提交一個任務。

issue不是一些Git平臺的專屬功能，JIRA等平臺也有相似功能，它們的做用大同小異，均可以很好地反應項目的成長情況和參與度。那麼在Git提交時，咱們能夠在foot區域關聯本次提交涉及的issue。

# 涉及
issues  #F12YC,#F45JW
# 關閉
Closes #F12YC

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

3. 工具安利

說了這麼多，相信你已經對Git提交的規範有所瞭解了。這裏推薦一些有用的工具來幫助你將這些規範落實到位。在Intellij IDEA的插件市場有不少Git Commit Message模板插件，能夠可視化的實現這些規範。

你能夠去插件市場搜索獲取相關的插件。好了今天的分享就到這裏，多多關注：碼農小胖哥，學習更多有用的編程實用技巧。

關注公衆號：Felordcn 獲取更多資訊

我的博客：https://felord.cn