name: Git 提交助手 description: 通过分析 git 差异来生成描述性提交消息。在用户请求帮助编写提交消息或审查暂存更改时使用。

Git 提交助手

快速开始

分析暂存更改并生成提交消息：

# 查看暂存更改
git diff --staged

# 基于更改生成提交消息
# (Claude 将分析差异并建议消息)

提交消息格式

遵循传统提交格式：

<类型>(<范围>): <描述>

[可选正文]

[可选页脚]

类型

feat: 新功能
fix: 错误修复
docs: 文档更改
style: 代码风格更改（格式化、缺少分号）
refactor: 代码重构
test: 添加或更新测试
chore: 维护任务

示例

功能提交：

feat(认证): 添加 JWT 认证

实现基于 JWT 的认证系统，包括：
- 登录端点与令牌生成
- 令牌验证中间件
- 刷新令牌支持

错误修复：

fix(api): 处理用户配置文件中的空值

防止在用户配置文件字段为空时崩溃。
在访问嵌套属性前添加空值检查。

重构：

refactor(数据库): 简化查询构建器

提取常见查询模式到可重用函数中。
减少数据库层的代码重复。

分析更改

审查即将提交的内容：

# 显示更改的文件
git status

# 显示详细更改
git diff --staged

# 显示统计信息
git diff --staged --stat

# 显示特定文件的更改
git diff --staged 路径/到/文件

提交消息指南

应做：

使用祈使语气（“添加功能”而非“添加了功能”）
保持第一行在 50 字符以内
首字母大写
摘要末尾不加句号
在正文中解释原因而不仅仅是内容

不应做：

使用模糊消息如“更新”或“修复东西”
在摘要中包含技术实现细节
在摘要行写段落
使用过去时

多文件提交

当提交多个相关更改时：

refactor(核心): 重构认证模块

- 将认证逻辑从控制器移动到服务层
- 提取验证到单独的验证器中
- 更新测试以使用新结构
- 添加认证流程的集成测试

破坏性更改：认证服务现在需要配置对象

范围示例

前端：

feat(ui): 添加加载旋转器到仪表板
fix(表单): 验证电子邮件格式

后端：

feat(api): 添加用户配置文件端点
fix(数据库): 解决连接池泄漏

基础设施：

chore(ci): 更新 Node 版本到 20
feat(docker): 添加多阶段构建

破坏性更改

清晰标记破坏性更改：

feat(api)!: 重构 API 响应格式

破坏性更改：所有 API 响应现在遵循 JSON:API 规范

先前格式：
{ "data": {...}, "status": "ok" }

新格式：
{ "data": {...}, "meta": {...} }

迁移指南：更新客户端代码以处理新响应结构

模板工作流程

审查更改：git diff --staged
识别类型：是 feat、fix、refactor 等吗？
确定范围：代码库的哪一部分？
写摘要：简短、祈使的描述
添加正文：解释原因和影响
注意破坏性更改：如适用

交互式提交助手

使用 git add -p 进行选择性暂存：

# 交互式暂存更改
git add -p

# 审查暂存内容
git diff --staged

# 提交消息
git commit -m "类型(范围): 描述"

修正提交

修复最后一次提交消息：

# 仅修正提交消息
git commit --amend

# 修正并添加更多更改
git add 忘记的文件.js
git commit --amend --no-edit

最佳实践

原子提交 - 每次提交一个逻辑更改
提交前测试 - 确保代码工作
引用问题 - 如适用，包括问题编号
保持专注 - 不要混合无关更改
为人类写作 - 未来的你会阅读这些

提交消息检查清单

[ ] 类型合适（feat/fix/docs/等）
[ ] 范围具体清晰
[ ] 摘要少于 50 字符
[ ] 摘要使用祈使语气
[ ] 正文解释原因而不仅仅是内容
[ ] 破坏性更改清晰标记
[ ] 包含相关问题编号