如何規範你的Git commit？

commit message應該如何寫才更清晰明瞭？團隊開發中有沒有遇到過讓人頭疼的git commit？本文分享在git commit規範建設上的實踐，規定了commit message的格式，並經過webhook在提交時進行監控，避免不規範的代碼提交。

Git每次提交代碼都須要寫commit message，不然就不容許提交。通常來講，commit message應該清晰明瞭，說明本次提交的目的，具體作了什麼操做……可是在平常開發中，你們的commit message千奇百怪，中英文混合使用、fix bug等各類籠統的message司空見怪，這就致使後續代碼維護成本特別大，有時本身都不知道本身的fix bug修改的是什麼問題。基於以上這些問題，咱們但願經過某種方式來監控用戶的git commit message，讓規範更好的服務於質量，提升你們的研發效率。

初期咱們在互聯網上搜索了大量有關git commit規範的資料，但只有Angular規範是目前使用最廣的寫法，比較合理和系統化，而且有配套的工具（IDEA就有插件支持這種寫法）。最後綜合阿里巴巴高德地圖相關部門已有的規範總結出了一套git commit規範。

commit message格式

<type>(<scope>): <subject>

type(必須)
用於說明git commit的類別，只容許使用下面的標識。
feat：新功能（feature）。
fix/to：修復bug，能夠是QA發現的BUG，也能夠是研發本身發現的BUG。
· fix：產生diff並自動修復此問題。適合於一次提交直接修復問題
· to：只產生diff不自動修復此問題。適合於屢次提交。最終修復問題提交時使用fix
docs：文檔（documentation）。
style：格式（不影響代碼運行的變更）。
refactor：重構（即不是新增功能，也不是修改bug的代碼變更）。
perf：優化相關，好比提高性能、體驗。
test：增長測試。
chore：構建過程或輔助工具的變更。
revert：回滾到上一個版本。
merge：代碼合併。
sync：同步主線或分支的Bug。
scope(可選)
scope用於說明 commit 影響的範圍，好比數據層、控制層、視圖層等等，視項目不一樣而不一樣。
例如在Angular，能夠是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。若是你的修改影響了不止一個scope，你可使用*代替。

subject(必須)
subject是commit目的的簡短描述，不超過50個字符。
建議使用中文（感受中國人用中文描述問題能更清楚一些）。
· 結尾不加句號或其餘標點符號。
· 根據以上規範git commit message將是以下的格式：

fix(DAO):用戶查詢缺乏username屬性 
feat(Controller):用戶查詢接口開發

以上就是咱們梳理的git commit規範，那麼咱們這樣規範git commit到底有哪些好處呢？
· 便於程序員對提交歷史進行追溯，瞭解發生了什麼狀況。
· 一旦約束了commit message，意味着咱們將慎重的進行每一次提交，不能再一股腦的把各類各樣的改動都放在一個git commit裏面，這樣一來整個代碼改動的歷史也將更加清晰。
· 格式化的commit message才能夠用於自動化輸出Change log。

監控服務

一般提出一個規範以後，爲了你們更好的執行規範，就須要進行一系列的拉通，好比分享給你們這種規範的優勢、能帶來什麼收益等，在你們都認同的狀況下最好有一些強制性的措施。固然git commit規範也同樣，前期咱們分享完規範以後考慮從源頭進行強制攔截，只要你們提交代碼的commit message不符合規範，直接不能提交。但因爲代碼倉庫操做權限的問題，咱們最終選擇了使用webhook經過發送警告的形式進行監控，督促你們按照規範執行代碼提交。除了監控git commit message的規範外，咱們還加入了大代碼量提交監控和刪除文件監控，減小研發的代碼誤操做。

總體流程

· 服務註冊：服務註冊主要完成代碼庫相關信息的添加。
· 重複校驗：防止merge request再走一遍驗證流程。
· 消息告警：對不符合規範以及大代碼量提交、刪除文件等操做發送告警消息。
· DB：存項目信息和git commit信息便於後續統計commit message規範率。
webhook是做用於代碼庫上的，用戶提交git commit，push到倉庫的時候就會觸發webhook，webhook從用戶的commit信息裏面獲取到commit message，校驗其是否知足git commit規範，若是不知足就發送告警消息；若是知足規範，調用gitlab API獲取提交的diff信息，驗證提交代碼量，驗證是否有重命名文件和刪除文件操做，若是存在以上操做還會發送告警消息，最後把全部記錄都入庫保存。

以上就是咱們整個監控服務的相關內容，告警信息經過以下形式發送到對應的釘釘羣裏：



咱們也有總體git commit的統計，統計我的的提交次數、不規範次數、不規範率等以下圖：

點擊獲取相關報警源碼文檔

將來思考

git hooks分爲客戶端hook和服務端hook。客戶端hook又分爲pre-commit、prepare-commit-msg、commit-msg、post-commit等，主要用於控制客戶端git的提交工做流。用戶能夠在項目根目錄的.git目錄下面配置使用，也能夠配置全局git template用於我的pc上的全部git項目使用。服務端hook又分爲pre-receive、post-receive、update，主要在服務端接受提交對象時進行調用。

以上這種採用webhook的形式對git commit進行監控就是一種server端的hook，至關於post-receive。這種方式並不能阻止代碼的提交，它只是經過告警的形式來約束用戶的行爲，但最終不規範的commit message仍是被提交到了服務器，不利於後面change log的生成。因爲公司代碼庫權限問題，咱們目前只能添加這種post-receive類型的webhook。如你們有更高的代碼庫權限，能夠採用server端pre-receive類型的webhook，直接拒毫不規範的git commit message。只要git commit規範了，咱們甚至能夠考慮把代碼和bug、需求關聯等等。

固然這塊咱們也能夠考慮客戶端的pre-commit，pre-commit在git add提交以後，而後執行git commit時執行，腳本執行沒錯就繼續提交，反之就會駁回。客戶端git hooks位於每一個git項目下的隱藏文件.git中的hooks文件夾裏。咱們能夠經過修改這塊的配置文件添加咱們的規則校驗，直接阻止不規範message的提交，也能夠經過客戶端commit-msg類型的hook進行攔截，把不規範扼殺在萌芽之中。修改每一個git項目下面.git目錄中的hooks文件你們確定以爲浪費時間，其實這裏能夠採用配置全局git template來完成。可是這又會涉及到hooks配置文件同步的問題。hooks配置文件在本地，如何讓hooks配置文件的修改能同步到全部使用的項目又成爲一個問題。因此使用服務端hook仍是客戶端hook須要根據具體需求作適當的權衡。

git hook不光能夠用來作規範限制，它還能夠作更多有意義的事情。一次git commit提交的信息量很大，有做者信息、代碼庫信息、commit等信息。咱們的監控服務就根據做者信息作了git commit的統計，這樣不只能夠用來監控commit message的規範性，也能夠用來監控你們的工做狀況。咱們也能夠把git commit和相關的bug關聯起來，咱們查看bug時就能夠查看解決這個bug的代碼修改，頗有利於相關問題的追溯。固然咱們用一樣的方法也能夠把git commit和相關的需求關聯起來，好比咱們定義一種格式feat *786990（需求的ID），而後在git commit的時候按照這種格式提交，webhook就能夠根據這種格式把需求和git commit進行關聯，也能夠用來追溯某個需求的代碼量，固然這個例子不必定合適，但足以證實git hook功能之強大，能夠給咱們的流程規範帶來很大的便利。

總結

編碼規範、流程規範在軟件開發過程當中是相當重要的，它可使咱們在開發過程當中少走不少彎路。Git commit規範也是如此，確實也是頗有必要的，幾乎不花費額外精力和時間，但在以後查找問題的效率卻很高。做爲一名程序員，咱們更應注重代碼和流程的規範性，永遠不要在質量上將就。

※更多文章和資料|點擊後方文字直達 ↓↓↓
100GPython自學資料包
阿里雲K8s實戰手冊
[阿里雲CDN排坑指南]CDN
ECS運維指南
DevOps實踐手冊
Hadoop大數據實戰手冊
Knative雲原生應用開發指南
OSS 運維實戰手冊
雲原生架構白皮書
Zabbix企業級分佈式監控系統源碼文檔