提交与PR约定
将 PR 标题和初始正文视为压缩合并将采用的精确提交信息。
提交信息
- 首先阅读仓库说明。使用仓库本地的
commit-scope技能推导作用域。若不可用，则使用明确的仓库规则，或省略作用域，切勿自行编造。 - 遵循常规提交规范：
<类型>[可选作用域][!]: <描述>。 - 目标长度 50 个字符，并描述变更后的行为。不要为了达到该目标而省略仓库要求的作用域；当作用域使得无法达到 50 字符时，保持剩余描述尽可能简洁实用。
- 用空行分隔主题、正文和脚注。
- 对于独立提交，正文每行在 72 个字符处换行。解释为何需要此变更、如何解决问题以及实质性的副作用。
- 将现有的工单键或链接放在脚注中，而非主题中：
Issue: PROJECT-123。当存在相关问题时，遵循仓库特定的脚注格式。当不存在问题时，省略脚注，而非编造Issue: N/A。 - 添加适用的常规提交脚注以及合作者的
Co-authored-by: 姓名 <邮箱>后记。 - 根据受影响的面选择类型，而非根据变更是否修复缺陷。
- 对于 CI、工作流和自动化变更（包括对该自动化的修复），使用
ci。 - 对于产品或运行时错误以及对外公开 API 边界的非特性变更，使用
fix。 - 对于特性，使用
feat；对于构建或依赖，使用build；对于非产品工具或配置，使用chore；仅限文档，使用docs；对于非语义编辑，使用style；对于内部重构，使用refactor；对于测试，使用test；对于性能，使用perf。 - 使用
!或BREAKING CHANGE脚注标记破坏性变更，而不改变原本准确的类型。 - 保持每个未压缩的开发提交连贯且符合规范。
fix(storage): preserve collated indexes
Normalize server-expanded collations before comparing index definitions.
Issue: PROJECT-123
拉取请求
- 将标题精确设置为预期的压缩提交主题。
- 将初始正文精确设置为预期的压缩提交正文和脚注。排除仅 PR 的前言、清单和实现日志。
- 不要手动换行 PR 正文；GitHub 会处理显示换行。
- 保持永久历史记录简洁：记录动机、实质性行为和副作用。
- 将实验、替代方案、广泛验证和实现时间线放在后续评论中。
- 发布一条后续评论，列出变更的行数，至少分为生产代码、测试和其他文件，以便审阅者在阅读变更前了解变更的权重分布；如何统计和呈现由你决定，并在差异发生实质性变化时刷新它。
- 随着实现的发展，更新标题和初始正文。
- 在打开、更新或合并之前，将
标题 + 空行 + 正文作为一条提交信息来阅读，并纠正任何不匹配。