在使用Git時你應該這樣提交代碼
1. 前言
目前大部分公司都在使用 Git 作為版本控制，每個程序員每天都要進行代碼的提交。很多開發者也包括我自己，有時候趕時間或者圖省事，就這么提交：
- git commit -m "修改bug,優化代碼"
過了一段，突然去查找一個具體的提交你會發現不是特別好找。因此我們需要規范我們的代碼提交來避免這種情況。同時良好的提交規范也有助于我們生成清晰的 ChangeLog，更利于同事之間的協作。
如果你想成為知名開源項目的貢獻者更要規范自己的代碼提交。
2. Git 提交規范
目前業內做的比較好的，比較具有參考價值的就是知名前端框架AngularJS的提交規范。我們先來看一個例子：
Git提交信息
對應的格式：
- <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給項目提交一個任務。
Git issue
issue不是一些 Git 平臺的專屬功能，JIRA 等平臺也有類似功能，它們的作用大同小異，都可以很好地反應項目的成長狀況和參與度。那么在 Git 提交時，我們可以在foot區域關聯本次提交涉及的issue。
- # 涉及issues
- issues #F12YC,#F45JW
- # 關閉
- Closes #F12YC
這里沒有固定格式，不過盡量去參考一些知名項目去做。
3. 工具安利
說了這么多，相信你已經對 Git 提交的規范有所了解了。這里推薦一些有用的工具來幫助你將這些規范落實到位。在Intellij IDEA的插件市場有很多 Git Commit Message 模板插件，可以可視化的實現這些規范。
Git提交信息插件
本文轉載自微信公眾號「碼農小胖哥」，可以通過以下二維碼關注。轉載本文請聯系碼農小胖哥公眾號。
