開發中的你的Git提交規範嗎？
- 2021 年 1 月 22 日
- 筆記
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 獲取更多資訊
