---

#复盘/0 #临时/备忘 #状态/待处理


## 一句话描述

[___git 提交信息前缀_____]

---
你想了解 Git 提交信息中像`feat`这类前缀（也叫提交类型标识）的含义、规范和使用场景，对吧？这些前缀是遵循**Conventional Commits（约定式提交）** 规范的核心，目的是让提交历史清晰可读，还能自动化生成 CHANGELOG、管理语义化版本。

### 常用的 Git 提交类型前缀及含义

以下是项目中最常用的前缀，每个前缀对应明确的代码变更场景：

| 前缀         | 全称 / 含义           | 适用场景举例                               |
| ---------- | ----------------- | ------------------------------------ |
| `feat`     | Feature（新功能）      | 新增用户注册功能、添加商品筛选接口                    |
| `fix`      | Fix（修复 Bug）       | 修复登录密码错误提示不显示、修复数据统计偏差               |
| `docs`     | Documentation（文档） | 更新 README、补充接口注释、修改使用说明              |
| `style`    | Style（格式）         | 调整代码缩进、补充分号、修改空格（不影响逻辑）              |
| `refactor` | Refactor（重构）      | 提取公共函数、优化代码结构（无功能 / 修复变更）            |
| `perf`     | Performance（性能）   | 优化列表渲染速度、减少接口请求耗时                    |
| `test`     | Test（测试）          | 添加单元测试、补充集成测试、修复测试用例                 |
| `build`    | Build（构建）         | 升级 webpack 版本、修改打包配置、调整依赖版本          |
| `ci`       | CI/CD（持续集成）       | 修改 GitHub Actions 配置、调整 Jenkins 流水线  |
| `chore`    | Chore（杂项）         | 删除无用文件、清理日志、修改.gitignore             |
| `revert`   | Revert（回滚）        | 回滚之前的错误提交（格式：`revert: feat: 新增xx功能`） |

### 规范的提交信息格式

完整的约定式提交格式通常为：

plaintext

```
<类型>[可选作用域]: <简短描述>

[可选的详细描述]

[可选的关闭Issue链接]
```

- **作用域**：说明修改的模块 / 范围，让提交更精准，比如`feat(login): 新增记住密码功能`、`fix(order): 修复订单支付状态更新失败`；
- **简短描述**：首字母小写，结尾不加标点，简洁说明变更（不超过 50 字符）。

### 示例

bash

运行

```
# 新功能（带作用域）
feat(shop): 新增商品收藏功能

# 修复Bug（带详细描述）
fix(cart): 修复购物车数量为0时仍显示小红点

用户删除所有商品后，购物车小红点未清空，原因是判断条件遗漏了数量为0的场景，现已补充。

# 文档变更
docs: 更新API文档中用户信息接口的参数说明

# 重构
refactor: 提取表单验证的公共方法到utils目录
```

### 总结

1. `feat`和`fix`是最核心的提交类型，直接关联语义化版本（`feat`对应小版本升级，`fix`对应补丁版本升级）；
2. 这些前缀遵循 Conventional Commits 规范，能统一团队提交风格，让提交历史一目了然；
3. 不同前缀对应不同变更场景，按需使用可大幅提升项目维护效率（比如排查 Bug 时只需筛选`fix`类型的提交）。