團隊管理之git提交規範:你們居然都不會寫commit記錄?| 週末學習

這是我參與更文挑戰的第5天,活動詳情查看: 更文挑戰javascript

本文已參與 週末學習計劃,點擊查看詳情。css

前言

正如上一篇博客說的,以前有同事老是喜歡格式化代碼後提交,凡是他更改過的文件,哪怕只有1行,整個文件也會被他格式化。回頭再看git提交記錄,好傢伙,歷史commit全被覆蓋了~前端

再看看以前某個小項目的git提交記錄:java

image.png

小老弟,這滿屏的1是怎麼回事?git

看到這裏,你可能覺得這是小公司不規範的提交記錄,實際上這並非僅僅是小公司的問題。若是團隊負責人沒有作好規範,同事水平參差不齊,無論大公司仍是小公司,都會有這樣的問題。從這點來看,團隊中git提交規範是頗有必要的,那麼git提交都應該注意哪些問題呢?今天,大冰塊就來好好理一下git提交那點事兒~程序員

commit 三要素

主流的提交規範通常包括:標題(類型、精簡總結)、內容、備註 。其中精簡總結 是必填的,類型 最好也填一下,其他都是選填。web

下面大冰塊來見到那介紹一下這三個方面具體都指的是什麼:npm

1、標題

標題分爲 類型改動範圍精簡總結 三部分:api

一、類型

規範的主要類型以下:性能優化

  • feat:新功能或功能變動相關
  • fix:修復bug相關
  • docs:改動了文檔,註釋相關
  • style:修改了代碼格式化相關,如刪除空格、改變縮進、單雙引號切換、增刪分號等,並不會影響代碼邏輯
  • refactor:重構代碼,代碼結構的調整相關(理論上不影響現有功能)
  • perf:性能改動,性能、頁面等優化相關
  • test:增長或更改測試用例,單元測試相關
  • build: 影響編譯的更改相關,好比打包路徑更改、npm過程更改等
  • ci:持續集成方面的更改。如今有些build系統喜歡把ci功能使用yml描述。若有這種更改,建議使用ci
  • chore:其它改動相關,好比文件的刪除、構建流程修改、依賴庫工具更新增長等
  • revert:回滾版本相關

其實實際開發中最經常使用的就是 feat、fix 和 perf,git提交基本上都是實現需求,更改bug,性能優化。除了上述這些主要類型,咱們也能夠根據團隊要求定製類型,畢竟規範是死的,人是活的嘛。好比爲了你們更易讀,咱們只留幾個經常使用的,而且全改爲中文,如:

  • 功能更改:新功能或功能變動相關
  • 修復bug:修復bug相關
  • 優化:性能改動,性能、頁面等優化相關

沒有好與很差之分,適合團隊的就是最好的!

二、改動範圍

當項目劃分爲好幾個模塊的時候,指定改動的模塊是頗有必要的事情,這樣在git提交記錄中,很容易看出提交者更改的是哪一個模塊。好比本次修改了compiler(編譯器)模塊,下次修改了 router(路由)模塊,一目瞭然。如:

  • compiler
  • router

三、精簡總結

必填的精簡總結是很是重要的,通常是是總結歸納的文字。要讓人一眼就能看出來主要提交了什麼,是添加了功能仍是解決了問題,同時它也是大多數git管理工具默認展現的一行。若是你寫的標準,那麼提交記錄看起來就很漂亮很規整。例如:

fix: 修復了無限抽獎的bug
複製代碼

2、內容

內容主要填寫詳細的改動內容,可換行。固然,沒必要像寫一篇小做文似的長篇大論,畢竟咱們程序員的時間仍是很寶貴的。若是精簡總結寫的比較完美,內容不寫也是不要緊的。不過若是更改確實不少,而且時間充裕的話,把本次提交內容的實現、需求以及背景都填寫,是很負責的作法。好比:

fix: 修復了無限抽獎的bug

  在網絡很差時,屢次抽獎的接口能夠被重複調用。
  這次更改了抽獎接口的邏輯斷定,在併發請求中……採用了……因此……。
複製代碼

3、備註

備註看起來並非那麼重要,主要做用就是有一些額外的hook補充,好比提交記錄以後,自動觸發代碼聯動編譯,或者自動生成git提交的通知。

後記

規範了團隊的git提交,commit log記錄一目瞭然,配合自動化集成工具便可自動生成git change log。以及調用郵箱接口提示,自動發送提交、構建、發版的人員記錄,因此團隊管理的git的提交規範是頗有必要的,甚至是不可或缺的一部分。

本文旨在提供git規範化提交的思路,提早發現問題,解決問題,不至於在翻看git記錄時一臉懵。若是對你有幫助,點個贊就好,若是有錯誤歡迎指出交流。感謝閱讀~

PS: 今天是參加掘金更文挑戰的第5天啦,沒有存稿的我,週六依然戰戰兢兢的努力更文,不知道何時才能一小時搞定一篇博客呢?

雖然沒多少人看,也仍是給本身引引流吧~ 更文挑戰的文章目錄以下:

相關文章
相關標籤/搜索