Best Practices
提交信息规范约定
统一提交信息结构（动词、范围、原因）提升日志可读性、问题追踪效率和跨团队协作透明度。
- 希望把 Git 用得更稳的个人或团队
- 准备建立协作规范的维护者
- 至少有一次真实协作经验
- 知道常见命令但还没形成稳定习惯
- 把建议当硬规则而忽略上下文
- 只记流程，不理解背后的协作边界
高质量提交信息不是形式主义，它直接影响回溯效率和发布可读性。
一个可落地的模板
<type>(<scope>): <summary>
正文建议补两点：
- 为什么改
- 有哪些风险或后续动作
确定变更范围选择类型前缀编写清晰描述
可读历史自动分类可生成文档
好的 message 不是写给自己看的，而是写给半年后的自己和同事看的。
示例
fix(auth): reject expired refresh token
Align backend token validation with new TTL rule.
Risk: may increase login retries for stale clients.
团队约定建议
- summary 用动词开头，尽量在 72 字符内
- 把“原因”写清，不只写“改了什么”
- 破坏性变更必须显式标注
PR 页面会被折叠或丢失上下文，commit 日志才是长期可检索的历史索引。
接下来建议继续看什么
commit hygieneprepare commits before pull requestsmall batch review