在团队协作中，统一的 Git 提交规范能极大提升沟通效率。除了大家熟悉的 feat 和 fix，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。
小结
Git 规范提交的核心是通过语义化前缀明确提交目的，常用前缀包括 feat、fix、refactor、docs、style、test、chore、perf 等。提交信息格式统一为「前缀：描述」，简洁且能精准体现修改内容。结合 Issue 编号、版本号等信息，可让提交记录更易追溯和管理。
