在团队协作中，统一的提交信息规范能显著提升代码库的可读性与维护效率。除了常见的 feat、fix 之外，还有很多不同类型的前缀可以让提交信息更清晰、更有语义。
业界通用的 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 等。提交信息格式统一为「前缀：描述」，简洁且能精准体现修改内容。结合 Issue 编号、版本号等信息，可让提交记录更易追溯和管理，这对后续的版本管理和自动化发布至关重要。
