用一個空行隔開標題和正文限制標題字數在 50 個字元內用大寫字母寫標題行不要用句號結束標題行在標題行使用祈使語氣正文在 72 個字元處換行使用正文解釋是什麼和為什麼，而不是如何做

就這些了吧。

介紹: 為什麼好的提交資訊如此重要

如果你對如何寫好 git 提交資訊沒有仔細想過，那你很可能沒有怎麼使用過 git log 和相關工具。這裡有一個惡性迴圈：因為提交的歷史資訊組織混亂而且前後矛盾，那後面的人也就不願意花時間去使用和維護它。 又因為沒有人去使用和維護它，提交的資訊就會一直組織混亂和前後矛盾。

但一個好的日誌是一個優美和有用的東西，一旦日誌處理的好，那麼git blame、revert、rebase、log、shortlog 和其它子命令都將發揮它們的作用。檢視別人的提交和 pull 請求是值得的，而且可以隨時獨立完成。理解幾個月或者幾年前發生的程式碼變動不僅變得可能，而且高效。

一個專案的長期成功依賴於（除了其它方面）它的可維護性，一個維護者最有力的工具就是專案的日誌。所以非常值得花時間學習如何正確地維護它。剛開始可能很麻煩，但很快會成為習慣，最終會成為人們自豪和生產力的源泉。

對於什麼是慣用的約定，即命名和格式等，大多數程式語言都已經形成慣例。這些約定千差萬別，但是大多數開發者都同意選擇一種並堅持下去，這比讓每個人自行其事導致混亂要好得多。

一個團隊提交日誌的方法應該一致 。為了建立一個有用的修改歷史，團隊應該首先對提交資訊的約定形成共識，至少明確以下三件事情：

風格。包含句語、自動換行間距、文法、大小寫、拼寫。把這些講清楚，不要讓大家猜，並儘可能保持簡單。最終的結果就是一份相當一致的日誌，不僅讓人讀起來很爽，而且可以定期閱讀。

內容。哪些資訊應該包含在提交資訊（如果有）的正文中？哪些不用？

元資料。如何引用問題跟蹤 ID，pull 請求編號等？

幸運地是，如何生成一個地道的 git 提交資訊已經有完善的約定。事實上，大部分都整合在 git 命令中，你不需要重新發明什麼。你只需要遵循如下七條規則，就可以像老手一樣提交日誌。

七條很棒的 git 提交資訊規則

1. 用一個空行隔開標題和正文

首先，不是每一個提交都需要標題和正文。有時簡單一行也可以，特別是當這個改動很簡單將來也不會變化。

不需要再多說什麼了。如果讀者想知道拼寫錯誤具體是什麼，她透過 git show，git diff 或者 git log -p 命令，就可以很容易地看到這個改動。

git 中標題和正文之間的差別還體現在許多其他的功能上，但前提是標題和正文之間要有空行，這才能正常工作。

2. 限制標題字數在50個字元內

50個字元不是一個硬性規定，只是一個經驗之談。把標題行限制在這個長度，既保證它們容易閱讀，也強迫作者去思考如何用最精簡的方式解釋發生了什麼。

小技巧：如果你發現很難總結，那你可能一次提交太多改動了。 爭取作原子的提交（一個題目對應一個單獨的提交）

GitHub 的介面充分考慮到這些約定。如果超過50個字元的限制，它會警告你；

3. 用大寫字母寫標題行

這個很簡單。標題行的首字母大寫。

4. 不要用句號結束標題行

標題行不需要考慮標點符號。而且如果希望保持在 50 個字元以內，慎用空格。

5. 在標題行使用祈使語氣

祈使語氣就是像給一個命令或指示一樣敘述或寫作。一些例子如下：

· 打掃你的房間

· 關門

· 倒垃圾

你現在讀到七個原則中的每一個都是用祈使語氣書寫的。（“正文在 72 個字元處換行”等）

祈使語氣聽起來有點粗魯；所以我們通常不使用它。但對 git 提交資訊的標題行而言，它確實很棒。一個原因是當 git 代表你建立一個提交時，它自己就是使用祈使語氣。

當你用祈使語氣編寫你的提交資訊時，你遵守了 git 內在的約定。例如：

· 重構 X 子系統以增加可讀性

· 更新新手入門的文件

· 釋出1.0.0版本

一開始這樣寫會有點尷尬。同樣是用來描述事實，我們更習慣用陳述方式去講話。這也就是為什麼提交資訊常常讀起來都是這樣：

· 用 Y 修正了問題

· X的改變行為

有時編寫的提交資訊像是一個內容的描述：

· 對損壞事物的更多修正

· 新酷的 API 方法

有一個簡單的規則，每次把它做正確就可以減少誤解。

一個格式正確的 git 標題行應該可以完成下面的句子：如果被採用，這個 commit 將把你的標題放在這裡

例如：

· 如果被採用，這個 commit 將會重構 X 子系統以增加可讀性

· 如果被採用，這個 commit 將會更新新手入門的文件

· 如果被採用，這個 commit 將移出棄用的方法

· 如果被採用，這個 commit 將釋出 1.0.0 版本

· 如果被採用，這個 commit 將從 user/branch 合併 #123 pull 請求

注意下面這些非祈使格式不能工作：

· 如果被採用，這個 commit 將用 Y 修正了問題

· 如果被採用，這個 commit 將X 的改變行為

· 如果被採用，這個 commit 將對損壞事物的更多修正

· 如果被採用，這個 commit 將新酷的 API 方法

記住：使用祈使語氣只在標題上是重要的。你在編寫正文的時候，可以放寬這一限制。

6. 正文在72個字元處換行

Git 從來不自動換行。當你編寫一個提交資訊的正文時，你必須考慮到正確的間距和手動換行。

推薦在72個字元處換行，這樣 git 有足夠的空間來縮排文字，還可以保持整體都在80個字元以內。

7. 使用正文解釋是什麼和為什麼，而不是如何做

這個提交是一個來自 Bittcoin Core 的好例子，解釋了什麼被改動了和為什麼：

看一下完整的 diff，可以想象作者當下花了多少時間提供這些上下文資訊，這大大節省了同伴和未來提交者的時間。如果他不這麼做，這些資訊可能就永遠消失了。

大多數情況下，你可以省去改動的具體實現細節。 在這點上，程式碼通常是不需加以說明的（如果程式碼太複雜需要文字解釋，可以使用程式碼註釋）。首先把你做這個改動的原因交待清楚 —— 改動前是如何工作的（和出了什麼問題），現在是如何工作的，以及為什麼你要採用這種方法解決問題。

小技巧

學著去熱愛命令列。拋棄 IDE。

擁抱命令列是明智的，理由就像 git 子命令那樣多。Git 是強大的，IDE 也是，但是表現的方式不同。我每天都使用 IDE （IntelliJ IDEA），也用過不少其它的IDE（Eclipse），但我看到整合 git 的IDE ，都無法企及命令列的方便和強大（一旦你瞭解它）。

要發揮 git 的全部火力，那就是命令列。

記住無論你使用 Bash 還是 Z shell，都可以使用 Tab 補齊指令碼來減輕記住子命令和開關的痛苦。