MorJS Git Commit 約定式提交規(guī)范

本文中的關(guān)鍵詞 “必須（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“應(yīng)當(dāng)（SHALL）”、“不應(yīng)當(dāng)（SHALL NOT）”、“應(yīng)該（SHOULD）”、“不應(yīng)該（SHOULD NOT）”、“推薦（RECOMMENDED）”、“可以（MAY）” 和 “可選（OPTIONAL）” ，其相關(guān)解釋參考 RFC 2119 。

1. 每個(gè)提交都必須使用類(lèi)型字段前綴，它由一個(gè)名詞構(gòu)成，諸如 feat 或 fix ，其后接可選的范圍字段，可選的 !，以及必要的冒號(hào)（英文半角）和空格。
2. 當(dāng)一個(gè)提交為應(yīng)用或類(lèi)庫(kù)實(shí)現(xiàn)了新功能時(shí)，必須使用 feat 類(lèi)型。
3. 當(dāng)一個(gè)提交為應(yīng)用修復(fù)了 bug 時(shí)，必須使用 fix 類(lèi)型。
4. 范圍字段可以跟隨在類(lèi)型字段后面。范圍必須是一個(gè)描述某部分代碼的名詞，并用圓括號(hào)包圍，例如： fix(parser):
5. 描述字段必須直接跟在 <類(lèi)型>(范圍) 前綴的冒號(hào)和空格之后。描述指的是對(duì)代碼變更的簡(jiǎn)短總結(jié)，例如： fix: array parsing issue when multiple spaces were contained in string 。
6. 在簡(jiǎn)短描述之后，可以編寫(xiě)較長(zhǎng)的提交正文，為代碼變更提供額外的上下文信息。正文必須起始于描述字段結(jié)束的一個(gè)空行后。
7. 提交的正文內(nèi)容自由編寫(xiě)，并可以使用空行分隔不同段落。
8. 在正文結(jié)束的一個(gè)空行之后，可以編寫(xiě)一行或多行腳注。每行腳注都必須包含一個(gè)令牌（token），后面緊跟 :<space> 或 <space># 作為分隔符，后面再緊跟令牌的值（受 git trailer convention 啟發(fā)）。
9. 腳注的令牌必須使用 - 作為連字符，比如 Acked-by (這樣有助于區(qū)分腳注和多行正文)。有一種例外情況就是 BREAKING CHANGE，它可以被認(rèn)為是一個(gè)令牌。
10. 腳注的值可以包含空格和換行，值的解析過(guò)程必須直到下一個(gè)腳注的令牌/分隔符出現(xiàn)為止。
11. 破壞性變更必須在提交信息中標(biāo)記出來(lái)，要么在 <類(lèi)型>(范圍) 前綴中標(biāo)記，要么作為腳注的一項(xiàng)。
12. 包含在腳注中時(shí)，破壞性變更必須包含大寫(xiě)的文本 BREAKING CHANGE，后面緊跟著冒號(hào)、空格，然后是描述，例如：BREAKING CHANGE: environment variables now take precedence over config files 。
13. 包含在 <類(lèi)型>(范圍) 前綴時(shí)，破壞性變更必須通過(guò)把 ! 直接放在 : 前面標(biāo)記出來(lái)。如果使用了 !，那么腳注中可以不寫(xiě) BREAKING CHANGE:，同時(shí)提交信息的描述中應(yīng)該用來(lái)描述破壞性變更。
14. 在提交說(shuō)明中，可以使用 feat 和 fix 之外的類(lèi)型，比如：docs: updated ref docs. 。
15. 工具的實(shí)現(xiàn)必須不區(qū)分大小寫(xiě)地解析構(gòu)成約定式提交的信息單元，只有 BREAKING CHANGE 必須是大寫(xiě)的。
16. BREAKING-CHANGE 作為腳注的令牌時(shí)必須是 BREAKING CHANGE 的同義詞。