commit message應該如何寫才更清晰明瞭?團隊開發中有沒有遇到過讓人頭疼的git commit?本文分享在git commit規範建設上的實踐,規定了commit message的格式,並經過webhook在提交時進行監控,避免不規範的代碼提交。git
Git每次提交代碼都須要寫commit message,不然就不容許提交。通常來講,commit message應該清晰明瞭,說明本次提交的目的,具體作了什麼操做……可是在平常開發中,你們的commit message千奇百怪,中英文混合使用、fix bug等各類籠統的message司空見怪,這就致使後續代碼維護成本特別大,有時本身都不知道本身的fix bug修改的是什麼問題。基於以上這些問題,咱們但願經過某種方式來監控用戶的git commit message,讓規範更好的服務於質量,提升你們的研發效率。程序員
初期咱們在互聯網上搜索了大量有關git commit規範的資料,但只有Angular規範是目前使用最廣的寫法,比較合理和系統化,而且有配套的工具(IDEA就有插件支持這種寫法)。最後綜合阿里巴巴高德地圖相關部門已有的規範總結出了一套git commit規範。web
<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信息,驗證提交代碼量,驗證是否有重命名文件和刪除文件操做,若是存在以上操做還會發送告警消息,最後把全部記錄都入庫保存。oop
以上就是咱們整個監控服務的相關內容,告警信息經過以下形式發送到對應的釘釘羣裏:
咱們也有總體git commit的統計,統計我的的提交次數、不規範次數、不規範率等以下圖:
點擊獲取相關報警源碼文檔gitlab
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企業級分佈式監控系統源碼文檔