Git 提交信息规范（常称为 Conventional Commits）定义了多种类型的前缀，使提交信息更清晰、更有语义。
完整的规范提交前缀及含义
以下是业界通用的 Conventional Commits 规范中常用的前缀，按使用场景分类，每个前缀都有明确的语义：
| 前缀 | 中文含义 | 使用场景举例 |
|---|---|---|
| feat | 新增功能 | feat: 新增商品详情页分享功能 |
| fix | 修复 Bug | fix: 修复移动端下拉刷新数据重复的问题 |
| refactor | 代码重构（无功能变更） | refactor: 重构订单列表组件，优化代码结构 |
| docs | 文档修改 | docs: 更新 README 中的接口使用说明 |
| style | 代码格式调整（无逻辑变更） | style: 格式化代码缩进，修正变量命名规范 |
| test | 测试相关 | test: 为用户登录接口添加单元测试 |
| chore | 琐碎工作（构建/工具等） | chore: 升级依赖包 axios 到 1.6.0 版本 |
| perf | 性能优化 | perf: 优化商品列表查询 SQL，提升接口响应速度 |
| build | 构建相关（打包/编译） | build: 调整 webpack 配置，减小打包体积 |
| ci | CI/CD 配置修改 | ci: 调整 GitHub Actions 自动化部署流程 |
| revert | 回滚提交 | revert: 回滚到 commit 1234567，撤销上一次的功能修改 |
| release | 版本发布 | release: 发布 v1.2.0 版本 |
规范提交信息的书写建议
- 格式统一：前缀 + 冒号 + 空格 + 简短描述（描述用中文/英文均可，建议中文更贴合团队习惯，首字母无需大写，结尾不加标点）。示例：
perf: 优化首页图片加载速度 - 描述简洁：尽量控制在 50 个字符以内，清晰说明本次提交的核心内容。
- 特殊场景补充：如果修复的是特定 Bug（如关联 Issue），可以在描述后补充：示例：
fix: 修复支付回调签名验证错误 #123（#123 为 Issue 编号）
总结
- Git 规范提交的核心是通过语义化前缀明确提交目的，常用前缀包括 feat/fix/refactor/docs/style/test/chore/perf 等；
- 提交信息格式统一为「前缀：描述」，简洁且能精准体现修改内容；
- 结合 Issue 编号、版本号等信息，可让提交记录更易追溯和管理。
