這是我參與更文挑戰的第5天,活動詳情查看: 更文挑戰javascript
本文已參與 週末學習計劃,點擊查看詳情。css
正如上一篇博客說的,以前有同事老是喜歡格式化代碼後提交,凡是他更改過的文件,哪怕只有1行,整個文件也會被他格式化。回頭再看git提交記錄,好傢伙,歷史commit全被覆蓋了~前端
再看看以前某個小項目的git提交記錄:java
小老弟,這滿屏的1是怎麼回事?git
看到這裏,你可能覺得這是小公司不規範的提交記錄,實際上這並非僅僅是小公司的問題。若是團隊負責人沒有作好規範,同事水平參差不齊,無論大公司仍是小公司,都會有這樣的問題。從這點來看,團隊中git提交規範是頗有必要的,那麼git提交都應該注意哪些問題呢?今天,大冰塊就來好好理一下git提交那點事兒~程序員
主流的提交規範通常包括:標題(類型、精簡總結)、內容、備註 。其中精簡總結 是必填的,類型 最好也填一下,其他都是選填。web
下面大冰塊來見到那介紹一下這三個方面具體都指的是什麼:npm
標題分爲 類型 、 改動範圍 、 精簡總結 三部分:api
規範的主要類型以下:性能優化
其實實際開發中最經常使用的就是 feat、fix 和 perf,git提交基本上都是實現需求,更改bug,性能優化。除了上述這些主要類型,咱們也能夠根據團隊要求定製類型,畢竟規範是死的,人是活的嘛。好比爲了你們更易讀,咱們只留幾個經常使用的,而且全改爲中文,如:
沒有好與很差之分,適合團隊的就是最好的!
當項目劃分爲好幾個模塊的時候,指定改動的模塊是頗有必要的事情,這樣在git提交記錄中,很容易看出提交者更改的是哪一個模塊。好比本次修改了compiler(編譯器)模塊,下次修改了 router(路由)模塊,一目瞭然。如:
必填的精簡總結是很是重要的,通常是是總結歸納的文字。要讓人一眼就能看出來主要提交了什麼,是添加了功能仍是解決了問題,同時它也是大多數git管理工具默認展現的一行。若是你寫的標準,那麼提交記錄看起來就很漂亮很規整。例如:
fix: 修復了無限抽獎的bug
複製代碼
內容主要填寫詳細的改動內容,可換行。固然,沒必要像寫一篇小做文似的長篇大論,畢竟咱們程序員的時間仍是很寶貴的。若是精簡總結寫的比較完美,內容不寫也是不要緊的。不過若是更改確實不少,而且時間充裕的話,把本次提交內容的實現、需求以及背景都填寫,是很負責的作法。好比:
fix: 修復了無限抽獎的bug
在網絡很差時,屢次抽獎的接口能夠被重複調用。
這次更改了抽獎接口的邏輯斷定,在併發請求中……採用了……因此……。
複製代碼
備註看起來並非那麼重要,主要做用就是有一些額外的hook補充,好比提交記錄以後,自動觸發代碼聯動編譯,或者自動生成git提交的通知。
規範了團隊的git提交,commit log記錄一目瞭然,配合自動化集成工具便可自動生成git change log。以及調用郵箱接口提示,自動發送提交、構建、發版的人員記錄,因此團隊管理的git的提交規範是頗有必要的,甚至是不可或缺的一部分。
本文旨在提供git規範化提交的思路,提早發現問題,解決問題,不至於在翻看git記錄時一臉懵。若是對你有幫助,點個贊就好,若是有錯誤歡迎指出交流。感謝閱讀~
PS: 今天是參加掘金更文挑戰的第5天啦,沒有存稿的我,週六依然戰戰兢兢的努力更文,不知道何時才能一小時搞定一篇博客呢?
雖然沒多少人看,也仍是給本身引引流吧~ 更文挑戰的文章目錄以下: