約定式提交規范
本文中的關鍵詞 “必須（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“應當（SHALL）”、“不應當（SHALL NOT）”、“應該（SHOULD）”、“不應該（SHOULD NOT）”、“推薦（RECOMMENDED）”、“可以（MAY）” 和 “可選（OPTIONAL）”
- 每個提交都必須使用類型字段前綴，它由一個名詞構成，諸如?
feat?或?fix?， 其后接可選的范圍字段，可選的?!，以及必要的冒號（英文半角）和空格。 - 當一個提交為應用或類庫實現了新功能時，必須使用?
feat?類型。 - 當一個提交為應用修復了 bug 時，必須使用?
fix?類型。 - 范圍字段可以跟隨在類型字段后面。范圍必須是一個描述某部分代碼的名詞，并用圓括號包圍，例如：?
fix(parser): - 描述字段必須直接跟在 <類型>(范圍) 前綴的冒號和空格之后。 描述指的是對代碼變更的簡短總結，例如：?fix: array parsing issue when multiple spaces were contained in string?。
- 在簡短描述之后，可以編寫較長的提交正文，為代碼變更提供額外的上下文信息。正文必須起始于描述字段結束的一個空行后。
- 提交的正文內容自由編寫，并可以使用空行分隔不同段落。
- 在正文結束的一個空行之后，可以編寫一行或多行腳注。每行腳注都必須包含 一個令牌（token），后面緊跟?
:<space>?或?<space>#?作為分隔符，后面再緊跟令牌的值腳注的令牌必須使用?-?作為連字符，比如?Acked-by?(這樣有助于 區分腳注和多行正文)。有一種例外情況就是?BREAKING CHANGE，它可以被認為是一個令牌。 - 腳注的值可以包含空格和換行，值的解析過程必須直到下一個腳注的令牌/分隔符出現為止。
- 破壞性變更必須在提交信息中標記出來，要么在 <類型>(范圍) 前綴中標記，要么作為腳注的一項。
- 包含在腳注中時，破壞性變更必須包含大寫的文本?
BREAKING CHANGE，后面緊跟著冒號、空格，然后是描述，例如：?BREAKING CHANGE: environment variables now take precedence over config files?。 - 包含在 <類型>(范圍) 前綴時，破壞性變更必須通過把?
!?直接放在?:?前面標記出來。 如果使用了?!，那么腳注中可以不寫?BREAKING CHANGE:， 同時提交信息的描述中應該用來描述破壞性變更。 - 在提交說明中，可以使用?
feat?和?fix?之外的類型，比如：docs: updated ref docs.?。 - 工具的實現必須不區分大小寫地解析構成約定式提交的信息單元，只有?
BREAKING CHANGE?必須是大寫的。 - BREAKING-CHANGE 作為腳注的令牌時必須是 BREAKING CHANGE 的同義詞。
為什么使用約定式提交
| 提交類型 | 標題 | 描述 | 表情符號 | 發布 | 包含在變更日志中 |
|---|---|---|---|---|---|
feat | 特征 | 一個新功能 | minor | true | |
fix | Bug修復 | 錯誤修復 | patch | true | |
docs | 文檔 | 僅文檔更改 | patch如果scope是readme | true | |
style | 風格 | 不影響代碼含義的更改（空格、格式、缺少分號等） | - | true | |
refactor | 代碼重構 | 既不修復錯誤也不添加功能的代碼更改 | - | true | |
perf | 性能改進 | 提高性能的代碼更改 | patch | true | |
test | 測試 | 添加缺失的測試或糾正現有的測試 | - | true | |
build | 構建 | 影響構建系統或外部依賴項的更改（示例范圍：gulp、broccoli、npm） | patch | true | |
ci | 持續集成 | 對我們的 CI 配置文件和腳本的更改（示例范圍：Travis、Circle、BrowserStack、SauceLabs） | - | true | |
chore | 家務活 | 不修改 src 或測試文件的其他更改 | - | true | |
revert | 還原 | 恢復之前的提交 | - | true |
)
