05 | 規範設計（下）：commit 信息風格迥异、難以閱讀，如何規範？

Go 語言項目開發實戰目錄_小明的筆記倉庫的博客-CSDN博客

今天，我們繼續學習非編碼類規範中的 Commit 規範。

我們在做代碼開發時，經常需要提交代碼，提交代碼時需要填寫 Commit Message（提交說明），否則就不允許提交。

而在實際開發中，我發現每個研發人員提交 Commit Message 的格式可以說是五花八門，有用中文的、有用英文的，甚至有的直接填寫“11111”。這樣的 Commit Message，時間久了可能連提交者自己都看不懂所錶述的修改內容，更別說給別人看了。

所以在 Go 項目開發時，一個好的 Commit Message 至關重要：

可以使自己或者其他開發人員能够清晰地知道每個 commit 的變更內容，方便快速瀏覽變更曆史，比如可以直接略過文檔類型或者格式化類型的代碼變更。

可以基於這些 Commit Message 進行過濾查找，比如只查找某個版本新增的功能：git log --oneline --grep "^feat|^fix|^perf"。

可以基於規範化的 Commit Message 生成 Change Log。

可以依據某些類型的 Commit Message 觸發構建或者發布流程，比如當 type 類型為 feat、fix 時我們才觸發 CI 流程。

確定語義化版本的版本號。比如 fix 類型可以映射為 PATCH 版本，feat 類型可以映射為 MINOR 版本。帶有 BREAKING CHANGE 的 commit，可以映射為 MAJOR 版本。在這門課裏，我就是通過這種方式來自動生成版本號。

總結來說，一個好的 Commit Message 規範可以使 Commit Message 的可讀性更好，並且可以實現自動化。那究竟如何寫一個易讀的 Commit Message 呢？

接下來，我們來看下如何規範 Commit Message。另外，除了 Commit Message 之外，我還會介紹跟 Commit 相關的 3 個重點，以及如何通過自動化流程來保證 Commit Message 的規範化。

Commit Message 的規範有哪些？

毫無疑問，我們可以根據需要自己來制定 Commit Message 規範，但是我更建議你采用開源社區中比較成熟的規範。一方面，可以避免重複造輪子，提高工作效率。另一方面，這些規範是經過大量開發者驗證的，是科學、合理的。

目前，社區有多種 Commit Message 的規範，例如 jQuery、Angular 等。我將這些規範及其格式繪制成下面一張圖片，供你參考：

在這些規範中，Angular 規範在功能上能够滿足開發者 commit 需求，在格式上清晰易讀，目前也是用得最多的。

Angular 規範其實是一種語義化的提交規範（Semantic Commit Messages），所謂語義化的提交規範包含以下內容：

Commit Message 是語義化的：Commit Message 都會被歸為一個有意義的類型，用來說明本次 commit 的類型。

Commit Message 是規範化的：Commit Message 遵循預先定義好的規範，比如 Commit Message 格式固定、都屬於某個類型，這些規範不僅可被開發者識別也可以被工具識別。

為了方便你理解 Angular 規範，我們直接看一個遵循 Angular 規範的 commit 曆史記錄，見下圖：

再來看一個完整的符合 Angular 規範的 Commit Message，如下圖所示：

 通過上面 2 張圖，我們可以看到符合 Angular Commit Message 規範的 commit 都是有一定格式，有一定語義的。

那我們該怎麼寫出符合 Angular 規範的 Commit Message 呢？

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

<type>[optional scope]: <description>

// 空行
[optional body]

// 空行
[optional footer(s)]

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

在實際開發中，為了使 Commit Message 在 GitHub 或者其他 Git 工具上更加易讀，我們往往會限制每行 message 的長度。根據需要，可以限制為 50/72/100 個字符，這裏我將長度限制在 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

接下來，我們詳細看看 Angular 規範中 Commit Message 的三個部分。

Header

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

我們先來說 type，它用來說明 commit 的類型。為了方便記憶，我把這些類型做了歸納，它們主要可以歸為 Development 和 Production 共兩類。它們的含義是：

Development：這類修改一般是項目管理類的變更，不會影響最終用戶和生產環境的代碼，比如 CI 流程、構建方式等的修改。遇到這類修改，通常也意味著可以免測發布。

Production：這類修改會影響最終的用戶和生產環境的代碼。所以對於這種改動，我們一定要慎重，並在提交前做好充分的測試。

我在這裏列出了 Angular 規範中的常見 type 和它們所屬的類別，你在提交 Commit Message 的時候，一定要注意區分它的類別。舉個例子，我們在做 Code Review 時，如果遇到 Production 類型的代碼，一定要認真 Review，因為這種類型，會影響到現網用戶的使用和現網應用的功能。

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

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

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

Angular 的 Commit Message 規範提供了大部分的 type，在實際開發中，我們可以使用部分 type，或者擴展添加我們自己的 type。但無論選擇哪種方式，我們一定要保證一個項目中的 type 類型一致。

接下來，我們說說 Header 的第二個字段 scope。

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

我們這門課采用的 scope，主要是根據組件名和功能來設置的。例如，支持 apiserver、authzserver、user 這些 scope。

這裏想强調的是，scope 不適合設置太具體的值。太具體的話，一方面會導致項目有太多的 scope，難以維護。另一方面，開發者也難以確定 commit 屬於哪個具體的 scope，導致錯放 scope，反而會使 scope 失去了分類的意義。

當然了，在指定 scope 時，也需要遵循我們預先規劃的 scope，所以我們要將 scope 文檔化，放在類似 devel 這類文檔中。這一點你可以參考下 IAM 項目的 scope 文檔： IAM commit message scope 。

最後，我們再說說 subject。

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

Body

Header 對 commit 做了高度概括，可以方便我們查看 Commit Message。那我們如何知道具體做了哪些變更呢？答案就是，可以通過 Body 部分，它是對本次 commit 的更詳細描述，是可選的。

Body 部分可以分成多行，而且格式也比較自由。不過，和 Header 裏的一樣，它也要以動詞開頭，使用現在時。此外，它還必須要包括修改的動機，以及和跟上一版本相比的改動點。

我在下面給出了一個範例，你可以看看：

The body is mandatory for all commits except for those of scope "docs". 
When the body is required it must be at least 20 characters long.

Footer

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

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 and
    the 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 image

Closes #1137

Revert Commit

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

revert: feat(iam-apiserver): add 'Host' option

This reverts commit 079360c7cfc830ea8a6e13f4c8b8114febc9b48a.

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

但是除了 Commit Message 規範之外，在代碼提交時，我們還需要關注 3 個重點內容：提交頻率、合並提交和 Commit Message 修改。

Commit 相關的 3 個重要內容

我們先來看下提交頻率。

提交頻率

在實際項目開發中，如果是個人項目，隨意 commit 可能影響不大，但如果是多人開發的項目，隨意 commit 不僅會讓 Commit Message 變得難以理解，還會讓其他研發同事覺得你不專業。因此，我們要規定 commit 的提交頻率。

那到底什麼時候進行 commit 最好呢？

我認為主要可以分成兩種情况。一種情况是，只要我對項目進行了修改，一通過測試就立即 commit。比如修複完一個 bug、開發完一個小功能，或者開發完一個完整的功能，測試通過後就提交。另一種情况是，我們規定一個時間，定期提交。這裏我建議代碼下班前固定提交一次，並且要確保本地未提交的代碼，延期不超過 1 天。這樣，如果本地代碼丟失，可以盡可能减少丟失的代碼量。

按照上面 2 種方式提交代碼，你可能會覺得代碼 commit 比較多，看起來比較隨意。或者說，我們想等開發完一個完整的功能之後，放在一個 commit 中一起提交。這時候，我們可以在最後合並代碼或者提交 Pull Request 前，執行 git rebase -i 合並之前的所有 commit。

那麼如何合並 commit 呢？接下來，我來詳細說說。

合並提交

合並提交，就是將多個 commit 合並為一個 commit 提交。這裏，我建議你把新的 commit 合並到主幹時，只保留 2~3 個 commit 記錄。那具體怎麼做呢？

在 Git 中，我們主要使用 git rebase 命令來合並。git rebase 也是我們日後開發需要經常使用的一個命令，所以我們一定要掌握好它的使用方法。

git rebase 命令介紹

git rebase 的最大作用是它可以重寫曆史。

我們通常會通過 git rebase -i <commit ID>使用 git rebase 命令，-i 參數錶示交互（interactive），該命令會進入到一個交互界面中，其實就是 Vim 編輯器。在該界面中，我們可以對裏面的 commit 做一些操作，交互界面如圖所示：

這個交互界面會首先列出給定<commit ID>之前（不包括，越下面越新）的所有 commit，每個 commit 前面有一個操作命令，默認是 pick。我們可以選擇不同的 commit，並修改 commit 前面的命令，來對該 commit 執行不同的變更操作。

git rebase 支持的變更操作如下：

在上面的 7 個命令中，squash 和 fixup 可以用來合並 commit。例如用 squash 來合並，我們只需要把要合並的 commit 前面的動詞，改成 squash（或者 s）即可。你可以看看下面的示例：

pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
s 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

rebase 後，第 2 行和第 3 行的 commit 都會合並到第 1 行的 commit。這個時候，我們提交的信息會同時包含這三個 commit 的提交信息：

# This is a combination of 3 commits.
# The first commit's message is:
Introduce OpenPGP and teach basic usage
# This is the 2ndCommit Message:
Fix PostChecker::Post#urls
# This is the 3rdCommit Message:
Hey kids, stop all the highlighting

如果我們將第 3 行的 squash 命令改成 fixup 命令：

pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
f 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend

rebase 後，還是會生成兩個 commit，第 2 行和第 3 行的 commit，都合並到第 1 行的 commit。但是，新的提交信息裏面，第 3 行 commit 的提交信息會被注釋掉：

# This is a combination of 3 commits.
# The first commit's message is:
Introduce OpenPGP and teach basic usage
# This is the 2ndCommit Message:
Fix PostChecker::Post#urls
# This is the 3rdCommit Message:
# Hey kids, stop all the highlighting

除此之外，我們在使用 git rebase 進行操作的時候，還需要注意以下幾點：

删除某個 commit 行，則該 commit 會丟失掉。

删除所有的 commit 行，則 rebase 會被終止掉。

可以對 commits 進行排序，git 會從上到下進行合並。

為了加深你的理解，我給你完整演示一遍合並提交。

合並提交操作示例

假設我們需要研發一個新的模塊：user，用來在平臺裏進行用戶的注册、登錄、注銷等操作，當模塊完成開發和測試後，需要合並到主幹分支，具體步驟如下。

首先，我們新建一個分支。我們需要先基於 master 分支新建並切換到 feature 分支：

$ git checkout -b feature/user
Switched to a new branch 'feature/user'

這是我們的所有 commit 曆史：

$ git log --oneline
7157e9e docs(docs): append test line 'update3' to README.md
5a26aa2 docs(docs): append test line 'update2' to README.md
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

接著，我們在 feature/user分支進行功能的開發和測試，並遵循規範提交 commit，功能開發並測試完成後，Git 倉庫的 commit 記錄如下：

$ git log --oneline
4ee51d6 docs(user): update user/README.md
176ba5d docs(user): update user/README.md
5e829f8 docs(user): add README.md for user
f40929f feat(user): add delete user function
fc70a21 feat(user): add create user function
7157e9e docs(docs): append test line 'update3' to README.md
5a26aa2 docs(docs): append test line 'update2' to README.md
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

可以看到我們提交了 5 個 commit。接下來，我們需要將 feature/user分支的改動合並到 master 分支，但是 5 個 commit 太多了，我們想將這些 commit 合並後再提交到 master 分支。

接著，我們合並所有 commit。在上一步中，我們知道 fc70a21是 feature/user分支的第一個 commit ID，其父 commit ID 是 7157e9e，我們需要將7157e9e之前的所有分支 進行合並，這時我們可以執行：

$ git rebase -i 7157e9e

執行命令後，我們會進入到一個交互界面，在該界面中，我們可以將需要合並的 4 個 commit，都執行 squash 操作，如下圖所示：

修改完成後執行:wq 保存，會跳轉到一個新的交互頁面，在該頁面，我們可以編輯 Commit Message，編輯後的內容如下圖所示：

#開頭的行是 git 的注釋，我們可以忽略掉，在 rebase 後，這些行將會消失掉。修改完成後執行:wq 保存，就完成了合並提交操作。

除此之外，這裏有 2 個點需要我們注意：

git rebase -i <commid ID>這裏的一定要是需要合並 commit 中最舊 commit 的父 commit ID。

我們希望將 feature/user 分支的 5 個 commit 合並到一個 commit，在 git rebase 時，需要保證其中最新的一個 commit 是 pick 狀態，這樣我們才可以將其他 4 個 commit 合並進去。

然後，我們用如下命令來檢查 commits 是否成功合並。可以看到，我們成功將 5 個 commit 合並成為了一個 commit：d6b17e0。

$ git log --oneline
d6b17e0 feat(user): add user module with all function implements
7157e9e docs(docs): append test line 'update3' to README.md
5a26aa2 docs(docs): append test line 'update2' to README.md
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

最後，我們就可以將 feature 分支 feature/user 的改動合並到主幹分支，從而完成新功能的開發。

$ git checkout master
$ git merge feature/user
$ git log --oneline
d6b17e0 feat(user): add user module with all function implements
7157e9e docs(docs): append test line 'update3' to README.md
5a26aa2 docs(docs): append test line 'update2' to README.md
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

這裏給你一個小提示，如果你有太多的 commit 需要合並，那麼可以試試這種方式：先撤銷過去的 commit，然後再建一個新的。

$ git reset HEAD~3
$ git add .
$ git commit -am "feat(user): add user resource"

需要說明一點：除了 commit 實在太多的時候，一般情况下我不建議用這種方法，有點粗暴，而且之前提交的 Commit Message 都要重新整理一遍。

修改 Commit Message

即使我們有了 Commit Message 規範，但仍然可能會遇到提交的 Commit Message 不符合規範的情况，這個時候就需要我們能够修改之前某次 commit 的 Commit Message。

具體來說，我們有兩種修改方法，分別對應兩種不同情况：

git commit --amend：修改最近一次 commit 的 message；
git rebase -i：修改某次 commit 的 message。

接下來，我們分別來說這兩種方法。

git commit --amend：修改最近一次 commit 的 message

有時候，我們剛提交完一個 commit，但是發現 commit 的描述不符合規範或者需要糾正，這時候，我們可以通過 git commit --amend 命令來修改剛剛提交 commit 的 Commit Message。具體修改步驟如下：

查看當前分支的日志記錄。

$ git log –oneline
418bd4 docs(docs): append test line 'update$i' to README.md
89651d4 docs(doc): add README.md

可以看到，最近一次的 Commit Message 是 docs(docs): append test line 'update$i' to README.md，其中 update$i 正常應該是 update1。

更新最近一次提交的 Commit Message

在當前 Git 倉庫下執行命令：git commit --amend，後會進入一個交互界面，在交互界面中，修改最近一次的 Commit Message，如下圖所示：

修改完成後執行:wq 保存，退出編輯器之後，會在命令行顯示，該 commit 的 message 的更新結果如下：

[master 55892fa] docs(docs): append test line 'update1' to README.md
 Date: Fri Sep 18 13:40:42 2020 +0800
 1 file changed, 1 insertion(+)

查看最近一次的 Commit Message 是否被更新

$ git log --oneline
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

可以看到最近一次 commit 的 message 成功被修改為期望的內容。

git rebase -i：修改某次 commit 的 message

如果我們想修改的 Commit Message 不是最近一次的 Commit Message，可以通過 git rebase -i <父 commit ID>命令來修改。這個命令在實際開發中使用頻率比較高，我們一定要掌握。具體來說，使用它主要分為 4 步。

查看當前分支的日志記錄。

$ git log --oneline
1d6289f docs(docs): append test line 'update3' to README.md
a38f808 docs(docs): append test line 'update$i' to README.md
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

可以看到倒數第 2 次提交的 Commit Message 是：docs(docs): append test line 'update$i' to README.md，其中 update$i 正常應該是 update2。

修改倒數第 2 次提交 commit 的 message。

在 Git 倉庫下直接執行命令 git rebase -i 55892fa，然後會進入一個交互界面。在交互界面中，修改最近一次的 Commit Message。這裏我們使用 reword 或者 r，保留倒數第二次的變更信息，但是修改其 message，如下圖所示：

修改完成後執行:wq 保存，還會跳轉到一個新的交互頁面，如下圖所示：

修改完成後執行:wq 保存，退出編輯器之後，會在命令行顯示該 commit 的 message 的更新結果：

[detached HEAD 5a26aa2] docs(docs): append test line 'update2' to README.md
 Date: Fri Sep 18 13:45:54 2020 +0800
 1 file changed, 1 insertion(+)
Successfully rebased and updated refs/heads/master.

Successfully rebased and updated refs/heads/master.說明 rebase 成功，其實這裏完成了兩個步驟：更新 message，更新該 commit 的 HEAD 指針。

注意：這裏一定要傳入想要變更 Commit Message 的父 commit ID：git rebase -i <父 commit ID>。

查看倒數第 2 次 commit 的 message 是否被更新。

$ git log --oneline
7157e9e docs(docs): append test line 'update3' to README.md
5a26aa2 docs(docs): append test line 'update2' to README.md
55892fa docs(docs): append test line 'update1' to README.md
89651d4 docs(doc): add README.md

可以看到，倒數第 2 次 commit 的 message 成功被修改為期望的內容。

這裏有兩點需要你注意：

Commit Message 是 commit 數據結構中的一個屬性，如果 Commit Message 有變更，則 commit ID 一定會變，git commit --amend 只會變更最近一次的 commit ID，但是 git rebase -i 會變更父 commit ID 之後所有提交的 commit ID。

如果當前分支有未 commit 的代碼，需要先執行 git stash 將工作狀態進行暫存，當修改完成後再執行 git stash pop 恢複之前的工作狀態。

Commit Message 規範自動化

其實，到這裏我們也就意識到了一點：Commit Message 規範如果靠文檔去約束，就會嚴重依賴開發者的代碼素養，並不能真正保證提交的 commit 是符合規範的。

那麼，有沒有一種方式可以確保我們提交的 Commit Message 一定是符合規範的呢？有的，我們可以通過一些工具，來自動化地生成和檢查 Commit Message 是否符合規範。

另外，既然 Commit Message 是規範的，那麼我們能不能利用這些規範來實現一些更酷的功能呢？答案是有的，我將可以圍繞著 Commit Message 實現的一些自動化功能繪制成了下面一張圖。

這些自動化功能可以分為以下 2 類：

Commit Message 生成和檢查功能：生成符合 Angular 規範的 Commit Message、Commit Message 提交前檢查、曆史 Commit Message 檢查。

基於 Commit Message 自動生成 CHANGELOG 和 SemVer 的工具。

我們可以通過下面這 5 個工具自動的完成上面的功能：

commitizen-go：使你進入交互模式，並根據提示生成 Commit Message，然後提交。

commit-msg：githooks，在 commit-msg 中，指定檢查的規則，commit-msg 是個脚本，可以根據需要自己寫脚本實現。這門課的 commit-msg 調用了 go-gitlint 來進行檢查。

go-gitlint：檢查曆史提交的 Commit Message 是否符合 Angular 規範，可以將該工具添加在 CI 流程中，確保 Commit Message 都是符合規範的。

gsemver：語義化版本自動生成工具。

git-chglog：根據 Commit Message 生成 CHANGELOG。

這些工具你先有個印象就好了，在後面的課程內容中，我會帶你通過實際使用來熟悉它們的用法。

總結

今天我向你介紹了 Commit Message 規範，主要講了業界使用最多的 Angular 規範。

Angular 規範中，Commit Message 包含三個部分：Header、Body 和 Footer。Header 對 commit 做了高度概括，Body 部分是對本次 commit 的更詳細描述，Footer 部分主要用來說明本次 commit 導致的後果。格式如下：

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

另外，我們也需要控制 commit 的提交頻率，比如可以在開發完一個功能、修複完一個 bug、下班前提交 commit。

最後，我們也需要掌握一些常見的提交操作，例如通過 git rebase -i 來合並提交 commit，通過 git commit --amend 或 git rebase -i 來修改 commit message。

課後練習

新建一個 git repository，提交 4 個符合 Angular 規範的 Commit Message，並合並前 2 次提交。

使用 git-chglog 工具來生成 CHANGEOG，使用 gsemver 工具來生成語義化版本號。