Git 提交规范
📖 概述
概述：
有时候没事看 GitHub 的时候，发现别人提交的代码描述前都有英文单词，比如 docs、perf 啥的，我就啥也没有，今天研究一下，规范一下提交方式。
规范的 Git 提交信息不仅能让项目历史更清晰，还能帮助团队协作和自动化工具（如生成 CHANGELOG）更好地工作。
📝 基本格式
<type>: <description>格式说明：
type：提交类型（必填）:：冒号（必填）- 空格：冒号后必须有一个空格（必填）
description：简短描述（必填）
示例：
feat: 增加用户注册功能🏷️ 提交类型详解
✨ feat: 新功能（feature）
用于提交新功能。
示例：
feat: 增加用户注册功能
feat: 添加邮箱验证模块🐛 fix: 修复 bug
用于提交 bug 修复。
示例：
fix: 修复登录页面崩溃的问题
fix: 解决数据库连接超时错误📚 docs: 文档变更
用于提交仅文档相关的修改。
示例：
docs: 更新 README 文件
docs: 完善 API 接口文档💄 style: 代码风格变动
用于提交仅格式化、标点符号、空白等不影响代码运行的变更。
示例：
style: 删除多余的空行
style: 统一代码缩进格式♻️ refactor: 代码重构
用于提交代码重构（既不是新增功能也不是修复 bug 的代码更改）。
示例：
refactor: 重构用户验证逻辑
refactor: 优化数据处理流程⚡ perf: 性能优化
用于提交提升性能的代码修改。
示例：
perf: 优化图片加载速度
perf: 减少数据库查询次数✅ test: 添加或修改测试
用于提交测试相关的内容。
示例：
test: 增加用户模块的单元测试
test: 完善登录功能的集成测试🔧 chore: 杂项
用于提交构建过程、辅助工具等相关的内容修改。
示例：
chore: 更新依赖库
chore: 配置 ESLint 规则📦 build: 构建系统变更
用于提交影响构建系统或外部依赖项的更改。
示例：
build: 升级 webpack 到版本 5
build: 添加 Vite 构建配置👷 ci: 持续集成配置变更
用于提交 CI 配置文件和脚本的修改。
示例：
ci: 修改 GitHub Actions 配置文件
ci: 添加自动部署脚本⏪ revert: 回滚
用于提交回滚之前的提交。
示例：
revert: 回滚 feat: 增加用户注册功能
revert: 撤销上次的性能优化💡 最佳实践
- 简洁明了：描述应该简短且具体，一般不超过 50 个字符
- 使用动词开头：如"增加"、"修复"、"更新"等
- 避免模糊描述：不要写"修改代码"、"更新文件"这样的描述
- 一次提交一个改动：每次提交只做一件事，便于回滚和追踪
- 使用中文或英文：保持团队统一的语言风格
📌 快速参考
| 类型 | 说明 | 图标 |
|---|---|---|
feat | 新功能 | ✨ |
fix | Bug 修复 | 🐛 |
docs | 文档变更 | 📚 |
style | 代码风格 | 💄 |
refactor | 代码重构 | ♻️ |
perf | 性能优化 | ⚡ |
test | 测试相关 | ✅ |
chore | 杂项 | 🔧 |
build | 构建系统 | 📦 |
ci | 持续集成 | 👷 |
revert | 回滚 | ⏪ |