git commit 如果不规范提交信息，想从 A分支 优选(cherry) 到 B分支，去找到之前提交信息，可以说非常痛苦。

提交信息全是：修复bug。几百次提交全是：修复Bug。乱七八糟的。

所以提交信息的时候的确要规范下提交的前置信息。下面列了一些常见的提交信息。

写这篇文章，我也翻了几个开源项目，也并没有统一的规范，真正规范是很难执行的，世界是一个烂摊子的组合。代码能跑就行，所以很多时候没必要太做一些形式的东西，自己愿意按照这个规则，就遵守。无法强制要求别人！

推荐写法：功能单词名(模块)：some word

fix(Login)：修复了输入密码不能登录的bug。

feat(Message)：实现了邮箱消息推送。

feat(打豆豆)：some word！

Git提交信息，可动态生成。经过AI生成 对话上下文 。正好补充在这里。
Github-Copilot IDEA-使用可参考：https://www.zanglikun.com/22071.html

# Git 提交信息规范（自行简化，避免直接使用消耗过多大模型的token）

## 基本规则

1. **提交信息必须使用中文**，简洁明了地描述提交内容
2. **注意关注 IDEA 选中的提交文件**，确保提交范围正确
3. **每次提交只做一件事**，避免混合多种类型的变更

## 提交格式

```
<类型>(<作用域>): <描述>

[可选的正文]

[可选的脚注]
```

### 类型说明

| 类型 | 说明 | 示例场景 |
|------|------|----------|
| `feat` | 新功能 | 新增登录功能、添加数据导出 |
| `fix` | 修复 Bug | 修复登录失败、解决数据显示错误 |
| `docs` | 文档变更 | 更新 README、添加 API 文档 |
| `style` | 代码格式化 | 代码缩进、去除多余空格 |
| `refactor` | 重构 | 优化代码结构，不改变功能 |
| `perf` | 性能优化 | 优化查询速度、减少内存占用 |
| `test` | 测试相关 | 添加单元测试、修改测试用例 |
| `chore` | 构建/工具变更 | 更新依赖、修改构建脚本 |
| `ci` | CI 配置变更 | 修改 Jenkins、GitHub Actions |
| `revert` | 撤销提交 | 撤销之前的错误提交 |

### 作用域说明

作用域应该是本次修改影响的模块或功能区域，举例如下：

- **功能模块**：`Login`、`Message`、`Dashboard`、`Report`
- **技术模块**：`Database`、`Cache`、`Security`、`Config`
- **业务模块**：`User`、`Order`、`Product`、`Payment`

## 提交示例

### 功能开发
```
feat(Login): 新增微信登录功能
feat(Message): 实现邮箱消息推送
feat(Dashboard): 添加数据可视化图表
```

### Bug 修复
```
fix(Login): 修复输入密码不能登录的 bug
fix(Database): 解决数据库连接超时问题
fix(Cache): 修复缓存穿透导致的性能问题
```

### 文档更新
```
docs(README): 更新项目部署说明
docs(API): 添加用户管理接口文档
```

### 代码重构
```
refactor(Service): 优化用户服务代码结构
refactor(Utils): 重构工具类，提高代码复用性
```

### 性能优化
```
perf(Query): 优化用户查询 SQL，提升响应速度
perf(Cache): 改进缓存策略，减少内存占用
```

## 提交最佳实践

### ✅ 推荐做法

1. **描述要具体**：
   - ✅ `fix(Login): 修复验证码过期后仍能登录的问题`
   - ❌ `fix: 修复 bug`

2. **一次提交一个功能**：
   - ✅ 分别提交：`feat: 添加用户注册` 和 `fix: 修复登录 bug`
   - ❌ 混合提交：`feat: 添加注册功能并修复登录 bug`

3. **使用现在时态**：
   - ✅ `添加`、`修复`、`优化`
   - ❌ `已添加`、`已修复`、`已优化`

### ❌ 避免的做法

- 提交信息过于简单：`更新`、`修改`、`bug`
- 提交信息使用英文（项目要求中文）
- 一次提交包含多个不相关的变更
- 提交信息与实际变更不符

## IDEA 提交操作提醒

1. **选择文件**：在 IDEA 的 Git 面板中，仔细检查要提交的文件
2. **查看差异**：点击文件查看具体变更内容
3. **填写信息**：按照本规范填写提交信息
4. **最终检查**：提交前再次确认文件选择和提交信息

## 特殊情况处理

### 紧急修复
```
fix(Critical): 紧急修复生产环境数据丢失问题
```

### 版本发布
```
chore(Release): 发布 v1.2.0 版本
```

### 依赖更新
```
chore(Deps): 升级 Spring Boot 到 2.7.0
```

---

**注意**：良好的提交信息不仅方便代码审查，也有助于后续的问题排查和版本管理。

分支命名法

在 Git 中创建分支时，良好的分支命名规范有助于团队协作和项目管理。以下是一些常见的命名约定，适用于不同的场景：

1. 功能开发 (Feature)

• 格式: feature/<功能描述>
• 示例: feature/user-authentication, feature/payment-integration

2. 修复问题 (Bugfix)

• 格式: bugfix/<问题描述>
• 示例: bugfix/fix-login-issue, bugfix/correct-typo-in-docs

3. 改进 (Improvement)

• 格式: improvement/<改进描述>
• 示例: improvement/optimize-query-performance, improvement/ui-enhancements

4. 特性请求 (Enhancement)

• 格式: enhancement/<特性描述>
• 示例: enhancement/add-search-functionality, enhancement/refactor-code-structure

5. 文档更新 (Documentation)

• 格式: docs/<文档描述>
• 示例: docs/update-installation-guide, docs/add-api-documentation

6. 实验性功能 (Experiment)

• 格式: experiment/<实验描述>
• 示例: experiment/new-ui-design, experiment/test-new-library

7. 版本发布 (Release)

• 格式: release/<版本号>
• 示例: release/v1.0.0, release/v2.1.0

8. 热修复 (Hotfix)

• 格式: hotfix/<热修复描述>
• 示例: hotfix/critical-bug-fix, hotfix/security-patch

9. 任务或票据 (Task/Ticket)

• 格式: task/<任务编号>-<简要描述>
• 示例: task/123-add-user-profile, task/456-improve-performance

10. 个人开发 (Personal)

• 格式: personal/<你的名字>-<功能描述>
• 示例: personal/john-doe/add-new-feature, personal/jane-doe/experiment-with-ui

注意事项

• 简洁明了: 尽量保持分支名称简洁，但要准确描述分支的目的。
• 使用小写字母: 通常建议使用小写字母，并用连字符 - 分隔单词，以提高可读性。
• 避免使用空格和特殊字符: 使用连字符或下划线代替空格，避免使用特殊字符。

通过遵循这些命名规范，你的分支将更具可读性，团队成员也能更容易理解每个分支的目的和内容。如果有特定的场景或需求，可以进一步讨论！