Git - 如何寫好你的提交信息？

時間 2019-11-06

標籤 git 如何寫好提交信息欄目 Git 简体版

原文原文鏈接

前言

平時咱們在提交的時候，確定是會對本身所作的事情作一些或多或少的說明。但怎麼寫好就不是那麼容易了。因而就跑到github上看看人家是怎麼寫的，或者Google下，看看有沒有什麼好的實踐經驗。特此作了總結，但願能拋磚引玉。css

壞栗子

咱們從壞栗子開講，這樣就有的對比了，也好對號入座。正如這個命令，10我的有9個絕對寫過。html

git commit -m "Fix login bug"

咱們還會這麼寫。react

git commit -am "Fix login bug"

也會這樣。git

git commit -am "Fix bug!"

很明顯，你是在說這個提交是在修改一個登陸的BUG，由於沒有拼寫錯誤因此我能大概看明白。但我要是管理員我就難過了，會有一大堆的問題席捲而來。心理會想大哥，你修得這個BUG是哪一個？哪一個登陸的？什麼樣的？怎麼改的？。~~而後你後脊樑骨發涼，由於有人在罵街。~~github

你也能夠這麼想，管理員能夠耐着性子把個人修改看完，這樣就不就好了？很差意思，這樣的話管理員會瘋的，因此不能夠這麼作。web

提倡的作法

粒度

說的是作的修改的粒度。若是你一天作了不少的修改，可是就只提交了一次，那麼你的粒度就有點大了。這樣在你描述你的行爲的時候就會顯得模糊，若是你詳細描述的話，提交信息會變得長篇大論。但也不要作一點提交一點，這樣粒度就會變得過小，會致使一天到晚在寫提交信息，沒有必要。shell

在我看來，這個事情真的只能憑感受提交，用經驗來作判斷。由於一個BUG可能可大可小，大的話，你就得分割修復。若是小，那麼就一次提交修復就可。express

粒度的掌握絕對會影響你的提交信息，由於兩者是一一對應的。vim

段落

還記得上學的時候，寫英語做文的三段法嗎？和那個差很少，開頭闡明觀點，中間論述觀點，最後總結。
這裏咱們把提交信息也分爲三段，具體以下。cookie

refactor($browser): remove private polling mechanism

The only feature of Angular using this mechanism was `$cookies`,
which no longer mirrors the browser cookie values and so does not
need to poll.

Closes #11222

感受如何？該有的有，該沒得沒。作了什麼？爲何這麼作？影響了什麼？能夠說是一目瞭然。

如今咱們來講說爲何這樣作好。

開頭

首先，開頭部分單起一行，這在git中就會作爲默認顯示的部分，在你查看提交信息的時候就會顯示這行，其餘的部分則在進一步查看的時候纔會顯示。

你能夠指定模塊，或者說明動做（Add - Update - Delete）。

中間

其次，在中間的部分就是你的詳細說明，這個時候就要你作一個全面的說明了。說說你大概搞了什麼東西，是怎麼搞的。

最後

最後的這句話有妙用，他會根據你提到的issue編號自動地關閉你的issue。固然這個和你使用的git服務端有關係，在gitlab中會用Fix來進行關閉。實現了必定的自動化，而後你的團隊的成員就會受到通知，多麼美好。

實際運用

三段式在一般狀況下是標配，固然也有例外。在沒有相關issue的時候，最後部分能夠省略掉。在標題解釋了全部的事情的時候，中間的部分能夠省略，如你重命名了一個文件，或者是刪除了一個文件的時候。因此說只寫一個標題也是能夠的，前提是夠準確。

像是這樣

Rename cropper.css -> cropper.scsss

或是

Add calendar setting file

寬度

是的，是寬度，不是長度。和代碼同樣，若是你平時注意的話，就不要讓你的代碼在一行上超過80，否則誰讀代碼都很差受，包括你本身。因此提交信息的寬度也有限制。

分別是標題不要超過50，內容部分不要超過70。你可能會想，寫的時候還要查字數好難過。其實稍微配置一下就能夠了，具體操做會在後面說道。

統一

只要統一了格式，那麼團隊的各位都會明白你要表達的意思，因此你徹底能夠撇開上面的建議本身另起一套。

規範提交信息的格式的目的就是能快速準確的表達信息，只要達到了這個目的就能夠。習慣而已。

小技巧

配置提交信息的寬度

我隨時可能忘記寬度的限制，因此要作一個設置，這樣就能自動的對提交信息作格式化了。對於這樣的設置要取決於你的git默認選擇的編輯器是什麼，通常都是vim什麼的。

在 ~/.vimrc 里加上下面的命令，而後就會有神奇的事情發生了。

例如我用webstorm就集成了這個功能，我也就沒有太折騰。

autocmd Filetype gitcommit setlocal spell textwidth=72

不要使用 -m 或者 --message 作提交

這個命令讓你可以在一次操做中就把信息提交了。看起來很好，但事實上就是這個命令讓你們懶惰了。真正好的提交信息真的很難用用一句話說好，你不是在給一行代碼作註釋，你是在給一連串的改變作出解釋。作了什麼？爲何這麼作？影響了什麼？至少得把這三個問題給回答了。當你認知在編輯器裏寫提交信息的時候，你會想起不少事，經驗之談。

好栗子

其實你們也是滿隨意的，但又很統一。

Jquery

shellCSS: Restore the hack to get pixels for .css('width') etc.

This hack turns out to be needed by Android 4.0-4.3.

Add a support test so that the hack is invoked only where needed.

Refs gh-1815
Refs gh-1820
Closes gh-1842

angular

fix(filterFilter): Fix filtering using an object expression when the …
…filter value is undefined

Fixes #10419
Closes #10424

backbone

Merge pull request #3443 from jridgewell/history-root

History's root

react

Sync out another jsx transform test.

We added this test internally and it never got added here. We haven't broken it
with any transforms *yet* but it's still good to actually run all of our tests
here too.

結語

不必定要把上面提到的全部的要求都強制的推給團隊的全部人，要因地制宜，但必定要規範。正如代碼的註釋，合適就好。但這個合適要讓人明白和清楚，沒有額外的廢話。

沒有最好的，只有合適的。

望你們看完能夠作點評。