提交规范
本文档描述了 Rin 项目的提交信息规范。遵循这些规范可以让我们自动生成变更日志和发布说明。
格式
每个提交信息应遵循以下格式:
类型
作用域
作用域是可选的,应指示受影响的代码区域:
api- 后端 API 变更client- 前端/客户端变更db- 数据库变更auth- 认证相关ui- UI 组件deps- 依赖项config- 配置文件docs- 文档release- 发布相关
主题
- 使用祈使语气("添加"而不是"添加了"或"添加")
- 首字母不大写
- 末尾不加句号
- 最多 50 个字符
好的示例:
feat(auth): 添加密码重置功能fix(api): 处理数据库空响应docs(readme): 更新安装说明
不好的示例:
feat: Added new feature(过去时态,首字母大写)fix: fixed the bug.(过去时态,末尾有句号)update stuff(无类型,描述模糊)
正文
- 使用祈使语气
- 每行 72 个字符处换行
- 解释做了什么和为什么,而不是怎么做
- 与主题之间用空行分隔
示例:
页脚
- 引用 Issue 和 PR:
Closes #123、Fixes #456 - 破坏性变更:
BREAKING CHANGE: 描述
示例:
示例
功能
Bug 修复
文档
破坏性变更
提交信息检查
我们建议使用 commitlint 来强制执行这些规范:
为什么?
- 自动生成变更日志:可以自动生成发布说明
- 清晰的历史记录:易于理解发生了什么变更以及为什么
- 语义化版本控制:帮助确定版本升级(feat=minor,fix=patch,breaking=major)
- 更好的协作:一致的格式使代码审查更容易
工具
-
Commitizen:交互式提交信息构建器
-
VS Code 扩展:"Conventional Commits" 用于自动完成
有问题?
如果您不确定提交类型或格式,请在您的 PR 中询问或参考仓库中现有的提交。