概述
約定式提交規(guī)范是一種基于提交消息的輕量級約定。 它提供了一組用于創(chuàng)建清晰的提交歷史的簡單規(guī)則； 這使得編寫基于規(guī)范的自動化工具變得更容易。 這個約定與 SemVer 相吻合， 在提交信息中描述新特性、bug 修復和破壞性變更。
提交說明的結構如下所示：
<類型>[可選的作用域]: <描述>
[可選的正文]
[可選的腳注]
提交說明包含了下面的結構化元素，以向類庫使用者表明其意圖：
-
fix: 類型 為
fix的提交表示在代碼庫中修復了一個 bug（這和語義化版本中的PATCH相對應）。 -
feat: 類型 為
feat的提交表示在代碼庫中新增了一個功能（這和語義化版本中的MINOR相對應）。 -
BREAKING CHANGE: 在可選的正文或腳注的起始位置帶有
BREAKING CHANGE:的提交，表示引入了破壞性 API 變更（這和語義化版本中的MAJOR相對應）。 破壞性變更可以是任意 類型 提交的一部分。 -
其它情況: 除
fix:和feat:之外的提交 類型 也是被允許的，例如 @commitlint/config-conventional（基于 Angular 約定）中推薦的chore:、docs:、style:、refactor:、perf:、test:及其他標簽。 我們也推薦使用improvement，用于對當前實現(xiàn)進行改進而沒有添加新功能或修復錯誤的提交。 請注意，這些標簽在約定式提交規(guī)范中并不是強制性的。并且在語義化版本中沒有隱式的影響（除非他們包含 BREAKING CHANGE）。
可以為提交類型添加一個圍在圓括號內(nèi)的作用域，以為其提供額外的上下文信息。例如feat(parser): adds ability to parse arrays.。
示例
包含了描述以及正文內(nèi)有破壞性變更的提交說明
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
包含了可選的 ! 字符以提醒注意破壞性變更的提交說明
chore!: drop Node 6 from testing matrix
BREAKING CHANGE: dropping Node 6 which hits end of life in April
不包含正文的提交說明
docs: correct spelling of CHANGELOG
包含作用域的提交說明
feat(lang): add polish language
為 fix 編寫的提交說明，包含（可選的） issue 編號
fix: correct minor typos in code
see the issue for details on the typos fixed
closes issue #12
約定式提交規(guī)范
本文中的關鍵詞 “必須（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“應當（SHALL）”、“不應當（SHALL NOT）”、“應該（SHOULD）”、“不應該（SHOULD NOT）”、“推薦（RECOMMENDED）”、“可以（MAY）” 和 “可選（OPTIONAL）” ，解釋參考 RFC 2119 中所述。
- 每個提交都必須使用類型字段前綴，它由一個名詞組成，諸如
feat或fix，其后接一個可選的作用域字段，以及一個必要的冒號（英文半角）和空格。 - 當一個提交為應用或類庫實現(xiàn)了新特性時，必須使用
feat類型。 - 當一個提交為應用修復了 bug 時，必須使用
fix類型。 - 作用域字段可以跟隨在類型字段后面。作用域必須是一個描述某部分代碼的名詞，并用圓括號包圍，例如：
fix(parser): - 描述字段必須緊接在類型/作用域前綴的空格之后。描述指的是對代碼變更的簡短總結，例如： fix: array parsing issue when multiple spaces were contained in string.
- 在簡短描述之后，可以編寫更長的提交正文，為代碼變更提供額外的上下文信息。正文必須起始于描述字段結束的一個空行后。
- 在正文結束的一個空行之后，可以編寫一行或多行腳注。腳注必須包含關于提交的元信息，例如：關聯(lián)的合并請求、Reviewer、破壞性變更，每條元信息一行。
- 破壞性變更必須標示在正文區(qū)域最開始處，或腳注區(qū)域中某一行的開始。一個破壞性變更必須包含大寫的文本
BREAKING CHANGE，后面緊跟冒號和空格。 - 在
BREAKING CHANGE:之后必須提供描述，以描述對 API 的變更。例如： BREAKING CHANGE: environment variables now take precedence over config files. - 在提交說明中，可以使用
feat和fix之外的類型。 - 工具的實現(xiàn)必須不區(qū)分大小寫地解析構成約定式提交的信息單元，只有
BREAKING CHANGE必須是大寫的。 -
可以在類型/作用域前綴之后，
:之前，附加!字符，以進一步提醒注意破壞性變更。當有!前綴時，正文或腳注內(nèi)必須包含BREAKING CHANGE: description
為什么使用約定式提交
- 自動化生成 CHANGELOG。
- 基于提交的類型，自動決定語義化的版本變更。
- 向同事、公眾與其他利益關系者傳達變化的性質。
- 觸發(fā)構建和部署流程。
- 讓人們探索一個更加結構化的提交歷史，以便降低對你的項目做出貢獻的難度。
FAQ
在初始開發(fā)階段我該如何處理提交說明？
我們建議你按照假設你已發(fā)布了產(chǎn)品那樣來處理。因為通常總 有人 使用你的軟件，即便那是你軟件開發(fā)的同事們。他們會希望知道諸如修復了什么、哪里不兼容等信息。
提交標題中的類型是大寫還是小寫?
大小寫都可以，但最好是一致的。
如果提交符合多種類型我該如何操作？
回退并盡可能創(chuàng)建多次提交。約定式提交的好處之一是能夠促使我們做出更有組織的提交和 PR。
這不會阻礙快速開發(fā)和迭代嗎？
它阻礙的是以雜亂無章的方式快速前進。它助你能在橫跨多個項目以及和多個貢獻者協(xié)作時長期地快速演進。
約定式提交會讓開發(fā)者受限于提交的類型嗎（因為他們會想著已提供的類型）？
約定式提交鼓勵我們更多地使用某些類型的提交，比如 fixes。除此之外，約定式提交的靈活性也允許你的團隊使用自己的類型，并隨著時間的推移更改這些類型。
這和 SemVer 有什么關聯(lián)呢？
fix 類型提交應當對應到 PATCH 版本。feat 類型提交應該對應到 MINOR 版本。帶有 BREAKING CHANGE 的提交不管類型如何，都應該對應到 MAJOR 版本。
我對約定式提交做了形如 @jameswomack/conventional-commit-spec 的擴展，該如何版本化管理這些擴展呢？
我們推薦使用 SemVer 來發(fā)布你對于這個規(guī)范的擴展（并鼓勵你創(chuàng)建這些擴展?。?/p>
如果我不小心使用了錯誤的提交類型，該怎么辦呢？
當你使用了在規(guī)范中但錯誤的類型時，例如將 feat 寫成了 fix
在合并或發(fā)布這個錯誤之前，我們建議使用 git rebase -i 來編輯提交歷史。而在發(fā)布之后，根據(jù)你使用的工具和流程不同，會有不同的清理方案。
當使用了不在規(guī)范中的類型時，例如將 feat 寫成了 feet
在最壞的場景下，即便提交沒有滿足約定式提交的規(guī)范，也不會是世界末日。這只意味著這個提交會被基于規(guī)范的工具錯過而已。
所有的貢獻者都需要使用約定式提交規(guī)范嗎？
并不！如果你使用基于 squash 的 Git 工作流，主管維護者可以在合并時清理提交信息——這不會對普通提交者產(chǎn)生額外的負擔。 有種常見的工作流是讓 git 系統(tǒng)自動從 pull request 中 squash 出提交，并向主管維護者提供一份表單，用以在合并時輸入合適的 git 提交信息。
關于
約定式提交規(guī)范受到了 Angular 提交準則的啟發(fā)，并在很大程度上以其為依據(jù)。
該規(guī)范的首個草案來自下面這些項目中若干貢獻者們的協(xié)作：
- conventional-changelog：一套從 git 歷史中解析出約定式提交說明的工具。
- bumped：一個用于發(fā)布軟件的工具，可以在為你的軟件發(fā)布新版本前后輕松地執(zhí)行操作。
- unleash：一個用于自動化軟件發(fā)行和發(fā)布生命周期的工具。
- lerna：一個用于管理宏倉庫（monorepo）的工具，源自 Babel 項目。
用于約定式提交的工具
- php-commitizen：一個用于創(chuàng)建遵循約定式提交規(guī)范提交信息的工具。 可配置，并且可以作為 composer 依賴項用于 PHP 項目，或可在非 PHP 項目中全局使用。
- conform：一個可用以在 git 倉庫上施加配置的工具，包括約定式提交。
- standard-version 基于 GitHub 的新 squash 按鈕與推薦的約定式提交工作流，自動管理版本和 CHANGELOG。
使用約定式提交的項目
- yargs：廣受歡迎的命令行參數(shù)解析器。
- istanbuljs：一套為 JavaScript 測試生成測試覆蓋率的開源工具和類庫。
- uPortal-home 和 uPortal-application-framework：用于增強 Apereo uPortal 的可選用戶界面。
- massive.js：一個用于 Node 和 PostgreSQL 的數(shù)據(jù)訪問類庫。
- electron：用 JavaScript、HTML 和 CSS 構建跨平臺應用。
- scroll-utility：一個居中元素和平滑動畫的滾屏工具包實例。
- Blaze UI：無框架開源 UI 套件。
- Monica：一個開源的人際關系管理系統(tǒng)。
轉載出處：https://www.conventionalcommits.org/zh-cn/v1.0.0-beta.4/
