name: git-commit-helper description: 通过分析git差异生成描述性提交信息。当用户需要帮助编写提交信息或审查暂存更改时使用。 author: Joseph OBrien status: unpublished updated: ‘2025-12-23’ version: 1.0.1 tag: skill type: skill

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

参考文件

references/GIT_COMMIT.template.md - 约定式提交格式模板，包含类型、范围和示例

最佳实践

原子提交 - 每次提交一个逻辑更改
提交前测试 - 确保代码正常工作
引用问题 - 如果适用则包含问题编号
保持专注 - 不要混合不相关的更改
为人而写 - 未来的你会阅读这些信息

提交信息检查清单

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