在 Angular 規范中，Commit Message 包含三個部分，分別是 Header、Body 和 Footer，格式如下：

<type>[optional scope]: <description>
// 空行
[optional body]
// 空行
[optional footer(s)]

其中，Header 是必需的，Body和 Footer 可以省略。在以上規范中，scope 必須用括號 () 括起來， [] 后必須緊跟冒號 ，冒號后必須緊跟空格，2 個空行也是必需的。

在實際開發中，我們往往會限制每行 message 的長度。根據需要，可以限制為 50/72/100 個字符，

以下是一個符合 Angular 規范的 Commit Message：

fix($compile): couple of unit tests for IE9
# Please enter the Commit Message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# ...Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.Closes #392
Breaks foo.bar api, foo.baz should be used instead

1. Header

Header 部分只有一行，包括三個字段：type（必選）、scope（可選）和 subject（必選）。

1.1 type

type 用來說明 commit 的類型。主要可以歸為 Development 和 Production 共兩類：

• Development：這類修改一般是項目管理類的變更，不會影響最終用戶和生產環境的代碼，比如 CI 流程、構建方式等的修改。遇到這類修改，通常也意味著可以免測發布。
• Production：這類修改會影響最終的用戶和生產環境的代碼。所以對于這種改動，我們一定要慎重，并在提交前做好充分的測試。

這里列出了 Angular 規范中的常見 type 和它們所屬的類別，你在提交 Commit Message 的時候，一定要注意區分它的類別。

有這么多 type，我們該如何確定一個 commit 所屬的 type 呢？這里我們可以通過下面這張圖來確定。

如果我們變更了應用代碼，那這次修改屬于代碼類。在代碼類中，有 4 種具有明確變更意圖的類型：feat、fix、perf 和 style；如果我們的代碼變更不屬于這 4 類，那就全都歸為 refactor 類，也就是優化代碼。

如果我們變更了非應用代碼，例如更改了文檔，那它屬于非代碼類。在非代碼類中，有 3 種具有明確變更意圖的類型：test、ci、docs；如果我們的非代碼變更不屬于這 3 類，那就全部歸入到 chore 類。

1.2 scope

scope 是用來說明 commit 的影響范圍的，它必須是名詞。顯然，不同項目會有不同的 scope。在項目初期，我們可以設置一些粒度比較大的 scope，比如可以按組件名或者功能來設置 scope；后續，如果項目有變動或者有新功能，我們可以再用追加的方式添加新的 scope。

1.3 subject

subject 是 commit 的簡短描述，必須以動詞開頭、使用現在時。比如，我們可以用 change，卻不能用 changed 或 changes，而且這個動詞的第一個字母必須是小寫。通過這個動詞，我們可以明確地知道 commit 所執行的操作。此外我們還要注意，subject 的結尾不能加英文句號。

2. Body

Header 對 commit 做了高度概括，可以方便我們查看 Commit Message。那我們如何知道具體做了哪些變更呢？

答案就是，可以通過 Body 部分，它是對本次 commit 的更詳細描述，是可選的。Body 部分可以分成多行，而且格式也比較自由。不過，和 Header 里的一樣，它也要以動詞開頭，使用現在時。此外，它還必須要包括修改的動機，以及和跟上一版本相比的改動點。

3. Footer

Footer 部分不是必選的，可以根據需要來選擇，主要用來說明本次 commit 導致的后果。在實際應用中，Footer 通常用來說明不兼容的改動和關閉的 Issue 列表，格式如下：

BREAKING CHANGE: <breaking change summary>
// 空行
<breaking change description + migration instructions>
// 空行
// 空行
Fixes #<issue number>

接下來，我給你詳細說明下這兩種情況：

• 不兼容的改動：如果當前代碼跟上一個版本不兼容，需要在 Footer 部分，以 BREAKING CHANG: 開頭，后面跟上不兼容改動的摘要。Footer 的其他部分需要說明變動的描述、變動的理由和遷移方法

BREAKING CHANGE: isolate scope bindings definition has changed andthe inject option for the directive controller injection was removed.To migrate the code follow the example below:Before:scope: {myAttr: 'attribute',}After:scope: {myAttr: '@',}The removed `inject` wasn't generaly useful for directives so there should be no code using it.

• 關閉的 Issue 列表：關閉的 Bug 需要在 Footer 部分新建一行，并以 Closes 開頭列出，例如：Closes #123。如果關閉了多個 Issue，可以這樣列出：Closes #123, #432, #886。例如:

Change pause version value to a constant for imageCloses #1137

4. Revert Commit

除了 Header、Body 和 Footer 這 3 個部分，Commit Message 還有一種特殊情況：如果當前 commit 還原了先前的 commit，則應以 revert: 開頭，后跟還原的 commit 的 Header。而且，在 Body 中必須寫成 This reverts commit ，其中 hash 是要還原的 commit 的 SHA 標識。例如：

revert: feat(iam-apiserver): add 'Host' optionThis reverts commit 079360c7cfc830ea8a6e13f4c8b8114febc9b48a.

為了更好地遵循 Angular 規范，建議你在提交代碼時養成不用 git commit -m，即不用 -m 選項的習慣，而是直接用 git commit 或者 git commit -a 進入交互界面編輯 Commit Message。這樣可以更好地格式化 Commit Message。

參考：
https://time.geekbang.org/column/article/380989

總結

以上是生活随笔為你收集整理的规范的 Commit Message的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。