Git 项目提供了一般准则，其中包括如何撰写提交消息。编写提交消息时，请遵循以下准则：
通用指南
在首行（提交的摘要）和额外的详细说明之间添加一个空行。
如果可能，请将第一行限制为 50 个字符，并将详细说明限制为每行 72 个字符。
- 建议提供详细说明，但如果第一行已充分说明更改，则可以省略。
- 50 个字符的限制并非硬性限制。
使用问题跟踪器集成，但不在第一行。
使用命令语气总结提交内容。例如，“修复了 file.cc 中的内存泄漏”，而不是“我修复了 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
添加 bug
如果您希望 Fuchsia Gerrit 知道此变更与哪个问题相关联，则需要添加 Bug: <issue-tracker-ID> 行。如需将多个问题与某项更改相关联，请在单独一行中列出每个 bug。例如：
[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: 行（其中包含要多次运行的测试）来自动获取 deflake 运行。
以下示例展示了提交消息中的 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 缺少某些特定的基础架构，因此无法测试某些行为变更。如果是，请在跟踪器中针对必要的基础设施支持创建问题，并在更改说明中提供 bug 编号，同时说明如何手动测试相应更改。
有时，人们会指定 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。