code团队代码约定式提交规范

info概述

约定式提交规范是一种轻量级的提交信息约定,它提供了一组简单规则来创建清晰的提交历史。本规范适用于团队中的 GitSVN 版本控制系统。

star规范的优势

auto_fix_high自动化变更日志

标准化的提交格式便于工具解析,自动生成项目变更历史

timeline语义化版本号

基于提交类型自动判断版本号递增规则

visibility清晰的项目历史

统一的格式让团队成员快速理解变更内容

rate_review便于代码审查

明确的提交类型和描述提高审查效率

forum降低沟通成本

规范化的描述减少歧义,提升团队协作效率

edit提交信息格式

architecture基本结构

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

category1. 类型(必需)

类型 描述 示例场景
feat 新功能 添加用户登录功能
fix 修复bug 修复登录页面验证码显示异常
docs 文档变更 更新API文档
style 代码格式调整 修复代码缩进,添加分号
refactor 重构代码 重构用户服务层代码
perf 性能优化 优化数据库查询性能
test 测试相关 添加用户模块单元测试
chore 构建过程或辅助工具变动 更新webpack配置
ci 持续集成相关 修改Jenkins构建脚本
build 构建系统或外部依赖变更 升级React版本到18.0
revert 回滚提交 回滚commit abc123

scatter_plot2. 作用域(可选)

作用域用于说明本次提交影响的范围,建议使用项目中的模块名、组件名或功能域:

description3. 描述(必需)

article4. 正文(可选)

note5. 脚注(可选)

code提交示例

lightbulb基础示例
# 新功能
feat(user): 添加用户头像上传功能

# 修复bug
fix(auth): 修复登录时密码长度验证错误

# 文档更新
docs: 更新项目README文档

# 重构
refactor(api): 重构用户信息获取接口
description带正文的示例
feat(payment): 支持微信支付

集成微信支付SDK,支持扫码支付和H5支付两种方式。
用户可以在订单页面选择微信支付完成付款。

Closes #234
warning破坏性变更示例
feat(api): 更新用户API返回格式

BREAKING CHANGE: 用户API返回的数据结构发生变化,
原来的 user_name 字段改为 username,
原来的 user_id 字段改为 id

account_tree提交流程图

以下流程图展示了约定式提交的标准流程:

流程图加载中...

flash_on快速参考检查清单

tips_and_updates最佳实践

star编写优质提交信息的技巧

build工具集成

auto_awesomeCommitizen - 交互式提交工具

帮助生成规范的提交信息,提供友好的命令行界面

# 全局安装
npm install -g commitizen cz-conventional-changelog

# 配置
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

# 使用 - 替代 git commit
git cz

verifiedCommitlint - 提交信息验证

验证提交信息格式,确保团队遵循统一规范

# 安装
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'

auto_storiesStandard-version - 自动化版本发布

基于约定式提交自动生成版本号和变更日志

# 安装
npm install --save-dev standard-version

# 配置 package.json
{
  "scripts": {
    "release": "standard-version"
  }
}

# 发布新版本
npm run release

rocket_launch团队实施建议

trending_up渐进式推广策略

第一阶段团队成员学习规范,鼓励但不强制使用

第二阶段Code Review时检查提交信息格式

第三阶段使用工具强制验证提交格式

第四阶段集成自动化工具,自动生成版本和变更日志

school培训和文档

help常见问题

help_outline一次提交包含多种类型的变更怎么办?

尽量将不同类型的变更拆分为多个提交。如果必须在一个提交中包含,选择主要的变更类型,在正文中说明其他变更。

help_outline作用域应该如何定义?

根据项目结构定义,保持团队内一致。可以是模块名、文件名、功能域等。建议在团队内部制定统一的作用域命名规范。

help_outline描述应该用中文还是英文?

建议团队统一标准。中文团队可以使用中文,便于理解;国际化团队建议使用英文。关键是保持一致性。

help_outline什么情况下需要写正文?

当描述无法完整说明变更内容时,或需要解释变更原因、影响范围时,应该添加正文。正文应该说明"为什么"做这个变更。

link参考资料

文档版本:v1.0 | 最后更新:2025年6月