约定式提交规范是一种轻量级的提交信息约定,它提供了一组简单规则来创建清晰的提交历史。本规范适用于团队中的 Git 和 SVN 版本控制系统。
标准化的提交格式便于工具解析,自动生成项目变更历史
基于提交类型自动判断版本号递增规则
统一的格式让团队成员快速理解变更内容
明确的提交类型和描述提高审查效率
规范化的描述减少歧义,提升团队协作效率
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
| 类型 | 描述 | 示例场景 |
|---|---|---|
| feat | 新功能 | 添加用户登录功能 |
| fix | 修复bug | 修复登录页面验证码显示异常 |
| docs | 文档变更 | 更新API文档 |
| style | 代码格式调整 | 修复代码缩进,添加分号 |
| refactor | 重构代码 | 重构用户服务层代码 |
| perf | 性能优化 | 优化数据库查询性能 |
| test | 测试相关 | 添加用户模块单元测试 |
| chore | 构建过程或辅助工具变动 | 更新webpack配置 |
| ci | 持续集成相关 | 修改Jenkins构建脚本 |
| build | 构建系统或外部依赖变更 | 升级React版本到18.0 |
| revert | 回滚提交 | 回滚commit abc123 |
作用域用于说明本次提交影响的范围,建议使用项目中的模块名、组件名或功能域:
user - 用户模块auth - 认证模块api - API接口ui - 用户界面db - 数据库config - 配置相关BREAKING CHANGE: 开头Closes #123 或 Fixes #456# 新功能
feat(user): 添加用户头像上传功能
# 修复bug
fix(auth): 修复登录时密码长度验证错误
# 文档更新
docs: 更新项目README文档
# 重构
refactor(api): 重构用户信息获取接口
feat(payment): 支持微信支付
集成微信支付SDK,支持扫码支付和H5支付两种方式。
用户可以在订单页面选择微信支付完成付款。
Closes #234
feat(api): 更新用户API返回格式
BREAKING CHANGE: 用户API返回的数据结构发生变化,
原来的 user_name 字段改为 username,
原来的 user_id 字段改为 id
以下流程图展示了约定式提交的标准流程:
流程图加载中...
帮助生成规范的提交信息,提供友好的命令行界面
# 全局安装
npm install -g commitizen cz-conventional-changelog
# 配置
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
# 使用 - 替代 git commit
git cz
验证提交信息格式,确保团队遵循统一规范
# 安装
npm install --save-dev @commitlint/config-conventional @commitlint/cli
# 配置 commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional']
}
# Git hook 集成
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'
基于约定式提交自动生成版本号和变更日志
# 安装
npm install --save-dev standard-version
# 配置 package.json
{
"scripts": {
"release": "standard-version"
}
}
# 发布新版本
npm run release
第一阶段团队成员学习规范,鼓励但不强制使用
第二阶段Code Review时检查提交信息格式
第三阶段使用工具强制验证提交格式
第四阶段集成自动化工具,自动生成版本和变更日志
尽量将不同类型的变更拆分为多个提交。如果必须在一个提交中包含,选择主要的变更类型,在正文中说明其他变更。
根据项目结构定义,保持团队内一致。可以是模块名、文件名、功能域等。建议在团队内部制定统一的作用域命名规范。
建议团队统一标准。中文团队可以使用中文,便于理解;国际化团队建议使用英文。关键是保持一致性。
当描述无法完整说明变更内容时,或需要解释变更原因、影响范围时,应该添加正文。正文应该说明"为什么"做这个变更。
文档版本:v1.0 | 最后更新:2025年6月