Git 專案提供一般指南，包括如何撰寫提交訊息。撰寫提交訊息時，請遵循下列規範：
一般原則
在第一個大寫行 (提交摘要) 和其他詳細說明之間新增空白行。
請盡可能將第一行限制在 50 個半形字元以內，並將詳細說明限制在每行 72 個半形字元以內。
- 建議提供詳細說明，但如果第一行已清楚說明變更內容，則可省略。
- 50 個字元的限制並非硬性規定。
使用問題追蹤工具整合功能，但不要放在第一行。
使用祈使語氣總結提交內容。例如「Fix memory leak in file.cc」，而非「I fixed a memory leak the file.cc」。
請勿提及相對時間點、私人網址、個人、私人 API 金鑰、密碼、使用者名稱等。
新增段落
標題行下方的段落會更詳細地說明變更內容。 請確保清楚說明變更的原因和意圖： 例如：
Adding Fuchsia Commit message style guide
This change centralizes all commit message style guide into one style
guide. It also removes duplicate content from existing pages and points
to the new style guide instead.
Change-Id: I307e5b24df4273661d22c52c81038de50600c76c
新增錯誤
如要讓 Fuchsia Gerrit 知道這項變更與哪個問題相關聯，請新增 Bug: <issue-tracker-ID> 行。如要將多個問題與變更建立關聯，請在不同行中列出每個錯誤。例如：
[parent][component] Update component in Fuchsia
Write the details of a commit message here.
Bug: 82657
Bug: 82658
Test: Added test X.
Bug: 和 Fixed: 的差異在於，Fixed: 會在您提交變更後自動為您關閉問題，而 Bug: 只會在您提交變更後針對問題留言。如果問題附有多項變更，請對最終變更之前的所有變更使用 Bug: 標記。在最後一次變更時使用 Fixed:，以便關閉問題。
指出多個步驟
執行需要跨多個存放區進行多個步驟的變更時 (例如，要軟性轉換在一個存放區中定義，並在其他存放區中使用的 API)，請參照最後一個步驟和下一個步驟，指出多個步驟。
審查人員和查看記錄的人員可以據此瞭解並瀏覽所有變更。建議盡可能在每個提交記錄中提供完成遷移的所有步驟 (但在某些情況下可能不切實際)。
以下是包含多個步驟的提交訊息範例：
Support for flexible enums (1/3)
Step 1 of 3. Adds support for flexible enums to fidlgen_go:
* For all enums, emit `IsUnknown()` method indicating whether the
value is unknown (or known). While relevant only for flexible enums,
it is possible to construct unknown strict enums using type casts.
* Emit an internal method `I_EnumIsStrict` indicating whether the enum
is strict or flexible. This method is read by the runtime, when
creating enum marshaler.
* For flexible enums, we generate a default unknown placeholder
Step 2: I1102f244aa5ab4545fab21218c1da90be08604ec
Step 3: If0a047a4db804a183e984676217b31e17b4af0ea
Test: fx test fidl_go_conformance at If0a047a4db804a183e984676217b31e17b4af0ea
Change-Id: Id71eb879e4d7dfabe228cc7b4e2fedb7f52db7b7
新增測試資訊
使用 Multiply 精簡
如果您新增了測試，可以加入 Multiply: 行，讓測試自動執行多次，藉此取得去不穩定性執行。
以下範例顯示提交訊息中的 Multiply:：
Correct internal items' visibility Part II
This CL marks some internal items with pub(crate), pub(super) or leaves
as private. Related CL: fxr/535942
Bug: 72941
Multiply: setui_service_tests
Multiply: setui_client_interface_test
Change-Id: I67e061edee1e81a6875bf26b752ba5687c4ced71
開發人員須負責對程式碼進行高品質的自動化測試。 審查人員有責任退回未包含足夠測試的變更。如要進一步瞭解如何在 Fuchsia 專案中導入可測試及已測試的程式碼，請參閱 Fuchsia 可測試性評量標準。
如要瞭解更多提交訊息選項，請參閱「提交訊息選項」指南。
說明測試程序
如果測試說明很複雜，請建立問題，並在變更說明中提供該問題的連結。如果變更並非要改變行為，請在提交訊息中註明。
在某些情況下，由於 Fuchsia 缺少特定基礎架構，因此無法測試某些行為變更。如果是，請在追蹤器中建立有關必要基礎架構支援的問題，並在變更說明中提供錯誤編號，此外，請說明如何手動測試變更。
有時，使用者會指定 Test: 標記，指出對變更執行的測試。
這行只是供人工審查員參考的指標，不會影響預先提交測試的行為。
在 Change-Id 前新增緩衝區行
提交變更時，系統會自動新增 Change-Id。如果您使用 git commit --amend，可能需要在其他行和 Change-Id 之間加入緩衝區行，以免 Gerrit 將 Change-Id 剖析為一般行，並在其中加入第二個 ID。
如需更具體的詳細資料，請參閱「Git 解譯尾碼規則」。
使用 Change-Id 參照相關變更
如要在提交訊息中參照其他 Gerrit 變更，請一律使用 Change-Id。
建議使用 Change-Id，因為：
只有在合併變更後，系統才會知道 git SHA。雖然可以提供指引，在一個案例中使用 Change-Id，在另一個案例中使用 git SHA，但建議採用統一的指引。此外，您無法使用 Git SHA 參照其他存放區。
變更的連結是由 Gerrit 指派，不屬於存放區的永久記錄。如果審查機制有所變更，Change-Id 仍會記錄在歷史記錄中，但變更編號不會。在極少數情況下，變更號碼可能會遺失，例如因為重新建立索引的問題。
舉例來說，如要參照新增 RFC-0042 的變更，請使用 I32b966810d21a249647887fa45b61720ad01714c，而非 Git SHA 5d40ee8c42d1b0e4d8b690786da12a0a947c1aaa 或變更的連結 https://fuchsia-review.googlesource.com/c/fuchsia/+/284569。