name: Git Commit Helper description: 通过分析Git差异生成描述性提交消息。当用户请求帮助编写提交消息或查看暂存更改时使用。 hooks: PostToolUse: - matcher: “Bash” hooks: - type: command command: “echo "[$(date)] Git Commit Helper: Analyzed git diff for commit message" >> ~/.claude/git-commit-helper.log”

Git 提交助手

快速开始

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

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

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

提交消息格式

遵循常规提交格式：

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

[可选正文]

[可选页脚]

类型

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

示例

功能提交：

feat(auth): 添加JWT认证

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

错误修复：

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

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

重构：

refactor(database): 简化查询构建器

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

分析更改

查看正在提交的内容：

# 显示更改的文件
git status

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

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

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

提交消息指南

应做：

使用命令式语气（“添加功能”而不是“添加了功能”）
保持第一行少于50个字符
首字母大写
摘要末尾无句号
在正文中解释为什么而不仅仅是什么

不应做：

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

多文件提交

当提交多个相关更改时：

refactor(core): 重构认证模块

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

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

范围示例

前端：

feat(ui): 向仪表板添加加载微调器
fix(form): 验证电子邮件格式

后端：

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

基础设施：

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

破坏性更改

清楚地指示破坏性更改：

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

BREAKING CHANGE: 所有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 forgotten-file.js
git commit --amend --no-edit

最佳实践

原子提交 - 每次提交一个逻辑更改
提交前测试 - 确保代码工作
参考问题 - 如果适用，包括问题编号
保持专注 - 不要混合不相关的更改
为人类编写 - 未来的您将阅读此内容

提交消息检查清单

[ ] 类型合适（feat/fix/docs等）
[ ] 范围具体清晰
[ ] 摘要少于50个字符
[ ] 摘要使用命令式语气
[ ] 正文解释为什么而不仅仅是什么
[ ] 破坏性更改明确标记
[ ] 包括相关的问题编号