目錄：

1. 提交操作規(guī)范
2. 提交說明規(guī)范
3. Angular提交說明規(guī)范

提交操作規(guī)范

為了保持分支提交歷史的清晰、獨(dú)立，在提交更改時(shí)，我們應(yīng)做到：

• 每一個(gè)提交都應(yīng)該是一個(gè)完整、獨(dú)立的變更單元；
• 撰寫符合提交說明規(guī)范 的提交說明信息；
• 對(duì)于修復(fù)錯(cuò)別字、添加遺漏的更改等等之類的提交應(yīng)與對(duì)應(yīng)的提交合并，不應(yīng)為其創(chuàng)建單獨(dú)的提交；

多個(gè)提交合并成一個(gè)的各種方法請(qǐng)看Git中合并多個(gè)提交的各種方法

提交說明規(guī)范

Git 每次提交代碼，都必須要寫 提交說明； Git 對(duì) 提交說明 的格式是沒有限制的，你想怎么寫就怎么寫，如下：

雜亂的提交說明

但是，類似這種沒有格式的提交說明有以下缺點(diǎn)：

• 不能很快分辨出提交的代碼是增加了新功能、還是修復(fù)了bug、還只是更新了文檔等等；
• 不能有效地過濾某一類提交，比如：只想查看修復(fù)bug類的提交；
• 不能根據(jù)需要過濾并導(dǎo)出提交信息，作為變更日志：比如，應(yīng)用的升級(jí)的新功能說明、問題修復(fù)說明等等；

為了 方便 查看、過濾 提交說明，我需要將提交說明格式化、規(guī)范化；目前，有多種 提交說明 的寫法規(guī)范。但我推薦 Angular提交說明規(guī)范，這是目前使用最廣的寫法，比較合理和系統(tǒng)化，并且有配套的工具。

關(guān)于 Angular提交說明規(guī)范 的詳細(xì)文章請(qǐng)見：

• Angular提交說明規(guī)范
• Commit message 和 Change log 編寫指南

下面是我對(duì) Angular提交說明規(guī)范 一個(gè)匯總描述；

Angular提交說明規(guī)范

Angular提交說明的格式如下：

• [] 表示可選的；
• <> 表示必須的；

<Type>[(Scope)]:<Subject>
<空一行>
[Body]
<空一行>
<Footer>

• 只有 Type 和 Subject 是必須的，其它的都是可選的；

• 提交說明包括三個(gè)部分：Header（第一行）、Body（可選） 和 Footer（可選），用空行分隔；其中 Body、Footer 都是可選的，可以省略；

• 任何一行都不得超過72、100個(gè)字符；這是為了避免自動(dòng)換行影響美觀

• Header：只占第一行，包括三個(gè)字段：Type（必需）、Scope（可選）和 Subject（必需）；

  • Type：必需；用于說明提交的類別，只允許使用下面7個(gè)標(biāo)識(shí)：

    • feat：新功能（feature）
    • fix：修補(bǔ)bug
    • doc：文檔（documentation），(很多規(guī)范里使用的是復(fù)數(shù) docs，但我更建議使用 doc)
    • style： 格式（不影響代碼運(yùn)行的變動(dòng)）
    • refactor：重構(gòu)（即不是新增功能，也不是修改bug的代碼變動(dòng)）
    • test：增加測(cè)試
    • chore：構(gòu)建過程或輔助工具的變動(dòng)

    如果type為feat和fix，則該 commit 將肯定出現(xiàn)在 Change log 之中。其他情況（doc、chore、style、refactor、test）由你決定，要不要放入 Change log，建議是不要。
    提示： 為了醒目，也可以為每個(gè) Type 分別指定一個(gè) Emoji 表情，將其放在 Type 前面 或 后面；

  • Scope：可選；用于說明提交的影響范圍，比如數(shù)據(jù)層、控制層、視圖層等等，視項(xiàng)目不同而不同。

  • Subject：提交目的 的簡(jiǎn)短描述；要求如下：

    • 不超過50個(gè)字符。
    • 以動(dòng)詞開頭，使用第一人稱現(xiàn)在時(shí)，比如 change，而不是 changed 或 changes
    • 第一個(gè)字母小寫
    • 結(jié)尾不加句號(hào) .

• Body：對(duì)本次提交的詳細(xì)描述，

  • 可以分成多行。
  • 使用第一人稱現(xiàn)在時(shí)，比如使用change而不是changed或changes。
  • 應(yīng)該說明代碼變動(dòng)的動(dòng)機(jī)，以及與以前行為的對(duì)比。

• Footer：Footer 部分只用于兩種情況。

  1. 不兼容變動(dòng)：如果當(dāng)前代碼與上一個(gè)版本不兼容，則 Footer 部分以 BREAKING CHANGE 開頭，后面是對(duì)變動(dòng)的描述、以及變動(dòng)理由和遷移方法。
  2. 關(guān)閉 Issue：如果當(dāng)前 提交 針對(duì)某個(gè) issue 的，那么可以在 Footer 部分用 Closes #234 關(guān)閉這個(gè) issue ；也可以用 Closes #123, #245, #992 一次關(guān)閉多個(gè) issue ；

• 特殊情況： 如果當(dāng)前 提交 用于撤銷以前的 提交，則：

  • Header 必須以 revert: 開頭，后面跟著被撤銷的提交的 Header。
  • Body 部分的格式是固定的，必須寫成This reverts commit <hash>.，其中的 hash 是被撤銷的 提交 的 SHA 標(biāo)識(shí)符。
    如果當(dāng)前提交 與 被撤銷的 提交，在同一個(gè)發(fā)布（release）里面，那么它們都不會(huì)出現(xiàn)在 Change log 里面。如果兩者在不同的發(fā)布，那么當(dāng)前 commit，會(huì)出現(xiàn)在 Change log 的 Reverts 小標(biāo)題下面。