3.3 KiB
3.3 KiB
#复盘/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目录
总结
feat和fix是最核心的提交类型，直接关联语义化版本（feat对应小版本升级，fix对应补丁版本升级）；- 这些前缀遵循 Conventional Commits 规范，能统一团队提交风格，让提交历史一目了然；
- 不同前缀对应不同变更场景，按需使用可大幅提升项目维护效率（比如排查 Bug 时只需筛选
fix类型的提交）。