溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“如何規范提交Git”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何規范提交Git”吧!
目前大部分公司都在使用Git作為版本控制，每個程序員每天都要進行代碼的提交。很多開發者也包括我自己，有時候趕時間或者圖省事，就這么提交：
git commit -m "修改bug,優化代碼"
過了一段，突然去查找一個具體的提交你會發現不是特別好找。因此我們需要規范我們的代碼提交來避免這種情況。同時良好的提交規范也有助于我們生成清晰的ChangeLog，更利于同事之間的協作。
如果你想成為知名開源項目的貢獻者更要規范自己的代碼提交。
目前業內做的比較好的，比較具有參考價值的就是知名前端框架AngularJS的提交規范。我們先來看一個例子：
對應的格式：
<type>[optional scope]: <description> # 空行 [optional body] # 空行 [optional footer]
更嚴格的項目可能提交要求使用英文描述，特別是國際化的開源項目。
根據上面這個例子我們來了解一下這個業界比較認可的Git提交規范。
refactor 表示本次提交的是重構代碼，也就是它是一個提交的類型type，除了refactor還有：
feat 新功能，顧名思義就是新需求的實現。
fix 修復，就是對bug的修復。
docs 文檔，主要用來描述文檔的變更。
style 主要是代碼風格相關的提交，比如格式化等。
refactor 重構代碼，對已有功能的重構，但是區別于bugfix。
test 測試相關的提交，不太常用。
chore 構建過程或輔助工具的變動，不太常用，比如之前用Maven，后面換成了Gradle。
每次提交聲明提交的type是必須的，它讓本次提交的作用一目了然。
用來表明本次提交影響的范圍，方便快速定位。你可以寫明影響的是哪個模塊（通常是模塊名稱）或者是哪個層（數據層、服務層、還是視圖層）。
就是上面的修改版權信息，是對本次提交的簡短描述概括。就像胖哥寫文章要起一個標題一樣，不要過長。
就是比較詳細描述本次提交涉及的條目，羅列代碼功能，這里胖哥習慣用markdown的列表語法，也就是用中劃線換行隔開條目。當然body不是必選的，如果subject能夠描述清楚的話。
描述與本次提交相關聯的break change或issue 。
指明本次提交是否產生了破壞性修改，類似版本升級、接口參數減少、接口刪除、遷移等。如果產生了上述的影響強烈建議在提交信息中寫明break change，有利于出問題時快速定位，回滾，復盤。
如果發現項目有bug、或者有優化的建議、甚至新增一個任務，就可以利用issue給項目提交一個任務。
issue不是一些Git平臺的專屬功能，JIRA等平臺也有類似功能，它們的作用大同小異，都可以很好地反應項目的成長狀況和參與度。那么在Git提交時，我們可以在foot區域關聯本次提交涉及的issue。
# 涉及 issues #F12YC,#F45JW # 關閉 Closes #F12YC
這里沒有固定格式，不過盡量去參考一些知名項目去做。
說了這么多，相信你已經對Git提交的規范有所了解了。這里推薦一些有用的工具來幫助你將這些規范落實到位。在Intellij IDEA的插件市場有很多Git Commit Message模板插件，可以可視化的實現這些規范。
到此，相信大家對“如何規范提交Git”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
