提交信息规范约定

学完这篇你会掌握什么

• 理解 提交信息规范约定 的核心作用和适用场景
• 掌握 提交信息规范约定 的基本用法和常用参数
• 统一提交信息结构（动词、范围、原因）提升日志可读性、问题追踪效率和跨团队协作透明度。
• 理解 一个可落地的模板 相关的概念
• 掌握 示例 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

高质量提交信息不是形式主义，它直接影响回溯效率和发布可读性。

先想一个问题

你的团队在 Git 使用上积累了一些习惯，但你不确定这些习惯是否最优——或者你刚经历过一次因为 Git 操作不当造成的事故，想知道怎么避免下次再犯。

一个可落地的模板

<type>(<scope>): <summary>

正文建议补两点：

• 为什么改
• 有哪些风险或后续动作

提交前

确定变更范围选择类型前缀编写清晰描述

→git commit

规范结果

可读历史自动分类可生成文档

好的 message 不是写给自己看的，而是写给半年后的自己和同事看的。

示例

fix(auth): reject expired refresh token

Align backend token validation with new TTL rule.
Risk: may increase login retries for stale clients.

团队约定建议

1. summary 用动词开头，尽量在 72 字符内
2. 把“原因”写清，不只写“改了什么”
3. 破坏性变更必须显式标注

!不要把 PR 描述替代 commit 信息

PR 页面会被折叠或丢失上下文，commit 日志才是长期可检索的历史索引。

接下来建议继续看什么

1. commit hygiene
2. prepare commits before pull request
3. small batch review

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• 高级提交信息规范
• 冲突处理惯例专题
• 先 fetch 再同步