75 lines
3.3 KiB
Markdown
75 lines
3.3 KiB
Markdown
|
||
---
|
||
|
||
#复盘/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`类型的提交）。 |