gen-commit

我希望你提供给我的内容

1. 符合 git 规范的 commit 标题和详细说明
2. 你认为合理的一个分支名称
3. 生成的 commit 信息必须是中文
4. 重点：提供便于代码评审人快速理解改动的完整信息

代码评审友好的 commit 信息要求

一个好的 commit 信息应该让评审人能够：

• 快速理解改动的背景和动机
• 明确知道改动的范围和影响
• 了解技术实现的关键点
• 知道如何验证改动的正确性

一些提示信息

1. 你可以通过命令：git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@' 知道当前仓库的主分支名称
2. 获取主分支名称后，需要与远端主分支进行对比，因为本地主分支代码可能落后
3. 当前本地的 origin 可能不是最新，应该先执行 git fetch origin 更新
4. 优先检查未 git add 的改动
5. 执行命令时避免交互操作，因为无法进行用户干预。推荐使用 --no-pager 选项

我的要求

基本要求：

• commit 标题符合 git 规范，简洁明确，不超过 50 字符
• 忽略当前分支名称（不具有参考价值）
• 仅提供 commit 信息建议，不执行实际的代码提交操作

Type 类型：

• feat：新增 feature
• fix：修复 bug
• docs：仅仅修改了文档，比如 README、CHANGELOG、CONTRIBUTE 等等
• style：仅仅修改了空格、格式缩进、逗号等等，不改变代码逻辑
• refactor：代码重构，没有加新功能或者修复 bug
• perf：优化相关，比如提升性能、体验
• test：测试用例，包括单元测试、集成测试等
• chore：改变构建流程、或者增加依赖库、工具等
• revert：回滚到上一个版本

分支命名规范：

• 使用前缀：feature/、bugfix/、docs/、test/
• 分支名简洁反映改动内容，采用 kebab-case 格式

Commit 信息结构要求：

<type>(<scope>): <subject>

## 改动说明
- 为什么改：<改动动机和问题背景>
- 改了什么：<具体的改动内容>
- 影响范围：<受影响的模块和兼容性>
- 验证方式：<测试方法或验证点>

输出格式：

<分支名称>

<type>(<scope>): <subject>

## 改动说明
- 为什么改：<改动动机和问题背景>
- 改了什么：<具体的改动内容>
- 影响范围：<受影响的模块和兼容性>
- 验证方式：<测试方法或验证点>

Commit 示例

示例 1：功能开发

feat(api): 新增用户认证接口

## 改动说明
- 为什么改：提升系统安全性，实现基于JWT的用户认证
- 改了什么：新增UserAuthController，实现register、login、refresh-token接口
- 影响范围：新增/api/auth/*路由，需要前端适配认证流程
- 验证方式：新增15个单元测试，集成测试验证完整流程

示例 2：Bug 修复

fix(core): 修复内存泄漏导致的性能问题

## 改动说明
- 为什么改：生产环境发现内存持续增长导致服务崩溃
- 改了什么：修复EventEmitter监听器未移除问题，优化内存管理
- 影响范围：核心服务内存使用优化约30%，API接口保持不变
- 验证方式：24小时压力测试验证内存稳定性

生成 Commit 时的注意事项

1. 保持真实性：基于实际代码改动生成信息，不要虚构不存在的内容
2. 突出重点：评审人最关心的是"为什么改"和"改了什么"
3. 具体明确：避免模糊的描述，如"优化了性能"应具体说明如何优化
4. 结构清晰：按照模板结构组织信息，便于快速阅读
5. 技术准确：确保技术实现描述的准确性和专业性