Commit Message Format

提交消息由標題、正文和可選的頁腳組成。 提交消息中的每一行的最大長度為 100 個字符。

當您單擊 Squash and merge 時，會出現兩個文本字段。 第一個用于輸入頁眉，第二個用于輸入正文和頁腳，如下圖所示：

下面是 header 的一個例子：

feat: introduce new facade signature and generic ngrx store state for fine-grained control of loading state (#124)

以下是相應的正文和頁腳的示例。 頁腳以 BREAKING CHANGE 開頭。 請注意，正文和頁腳由空行分隔：

The product, language and currency facades have been refactored. A generic reducer has been introduced for all entities that require fine-grained load, success and error state.

BREAKING CHANGE:

Product, language and currency facades have a new public interface.

Closes #123

header

提交標頭是對已完成工作的簡要總結。

當您單擊 Squash and merge 時，會自動填充標題字段。 但是，它與我們的提交指南格式不完全匹配。 請修改它以適應以下格式：

類型是強制性的，并且必須是以下之一：

docs：僅用于對文檔的更改

feat：用于新功能工作

fix：用于錯誤修復

perf：用于提高性能的代碼更改

refactor：對于既不修復錯誤也不添加功能的代碼更改

style：用于不影響代碼含義的更改，例如空格、格式、缺少分號等

test：用于添加缺失的測試或糾正現有的測試。

chore：用于與構建、CI、腳本、配置以及不符合上述任何類型的任何內容相關的更改。

在 change log 里，我們只包含 feat 和 fix.

subject

主題包含對更改的簡潔描述，并遵守以下規則：

主題是用現在時的祈使時態寫的。 例如，“add facades”，而不是“adds facades”或“added facades”。

• 主題消息的第一個字母是小寫的。
• 主題消息的末尾沒有句點。

PR Number

在標題的末尾，在括號中包含 GitHub PR 編號，如下所示：(#124)。

默認情況下，GitHub 會在此處自動包含拉取請求編號，因此您無需手動添加。 提交提交信息后，GitHub 會將 PR 號轉換為原始拉取請求的鏈接，這對于正在閱讀變更日志的任何人來說都非常方便。

body

正文輸入到標題字段下方的文本字段中。

以下是編寫正文的一些準則：

描述您正在解決的問題。 無論您的補丁是單行錯誤修復，還是 5000 行新代碼，都必須有一個潛在的問題促使您進行這項工作。 向審閱者明確修復的必要性，以便他們繼續閱讀。

從用戶的角度描述這種變化的影響。 應用程序崩潰和鎖定非常令人信服，但并非所有錯誤都那么明顯； 這一信息應在案文中提及。 即使在代碼審查期間發現了問題，也要描述您認為它可能對用戶產生的影響。

描述您所做更改的技術細節。 盡可能清楚地描述更改非常重要。 這將幫助審閱者驗證代碼的行為是否符合您的預期。

footer

如果您的問題包含重大更改，請以 BREAKING CHANGE: 開始頁腳：后跟空格或空行，然后是重大更改的描述。 您可以使用以下關鍵字在頁腳中指示一項或多項重大更改：

• BREAKING CHANGE
• BREAKING CHANGES

如果您的問題包含棄用，您可以使用類似的方法來中斷更改，并使用以下關鍵字：

• DEPRECATION
• DEPRECATED
• DEPRECATIONS

頁腳也是您應該引用正在修復的問題的地方（例如，關閉 #123 或修復 #123）。 有關格式的信息以及可用關鍵字的列表，請參閱 GitHub 幫助。 此外，一旦您將 PR 合并到默認存儲庫分支，它將自動關閉您的問題。

總結

以上是生活随笔為你收集整理的SAP 电商云 Spartacus UI 代码提交的 commit 信息规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。