Git Committer

这个 skill 帮助分析 git 变更内容并生成符合项目规范的 commit message。

何时使用

当用户出现以下情况时调用此 skill：

• 用户说"提交代码"、"commit"、"生成 commit message"
• 用户需要将当前的代码变更提交到 git 仓库
• 用户想要查看变更并生成提交信息
• 用户执行 git 相关操作时

工作流程

1. 查看 git 状态

   • 执行 git status 查看当前变更状态
   • 执行 git diff 查看未暂存的变更
   • 执行 git diff --cached 查看已暂存的变更

2. 环境配置文件过滤

   • 自动识别并过滤环境配置文件的修改
   • 常见的环境配置文件包括：
     • vite.config.ts/js
     • webpack.config.js
     • .env 及其变体文件
     • 其他构建工具配置文件
   • 这些文件的修改不会生成提交计划，直接忽略

3. 分析变更内容

   • 识别变更的文件类型和影响范围
   • 理解变更的目的和功能
   • 确定变更的类型（[feature]、[fix]、[update]、[docs]、[style]、[refactor]、[test]、[chore]、[bump] 等）

4. 判断是否需要拆分提交

   • 如果变更涉及多个功能点，必须按功能拆分提交
   • 如果变更涉及不同类型的修改（如同时有新功能和 bug 修复），必须拆分提交
   • 每个提交应该只做一件事，保持提交的原子性

5. 拆分提交策略

   • 按功能模块拆分：将同一功能相关的文件归为一组
   • 按变更类型拆分：将新功能、bug 修复、重构等分开提交
   • 按文件类型拆分：将代码变更、配置变更、文档变更分开提交
   • 每次提交前使用 git add 添加对应的文件，然后提交

6. 生成 commit message

   • 遵循项目使用的方括号格式规范
   • 格式：[type](scope): subject
   • subject 使用中文描述，首字母小写，不以句号结尾
   • 包含简洁的描述和必要的详细说明
   • 如果有相关 issue，添加引用
   • 标题最大宽度 100 字符

7. 用户确认流程

   • 必须先展示生成的 commit message 和提交计划，等待用户明确同意后再执行提交
   • 只有在用户明确确认后，才能执行 git commit -m "message"
   • 绝对禁止在未获得用户明确确认的情况下自动执行 git commit 命令
   • 必须在展示 commit message 后等待用户的明确回应，如"确认"、"可以"、"同意"等
   • 如果用户对 commit message 提出修改意见，必须根据用户意见调整后重新展示并等待确认
   • 如果需要拆分提交，必须为每个提交单独获得用户确认
   • 如果用户明确要求合并提交，则以用户为准

8. 执行提交

   • 根据用户确认的提交计划执行提交操作
   • 使用 git add 选择性添加文件
   • 执行 git commit -m "message" 提交变更
   • 确保环境配置文件不会被添加到提交中

9. 推送代码（可选）

   • 所有提交完成后，询问用户是否需要推送代码
   • 如果用户需要推送，调用 push-code skill 来处理推送操作

Commit 类型

• [feature]: 针对用户的新特性，而不是针对构建脚本的新特性
• [fix]: 针对用户修复的错误，而不是针对构建脚本的修复
• [update]: 特性更新、功能优化，而不是新增特性或修复 bug
• [docs]: 文档修改
• [style]: 不会影响代码含义的更改（空格，格式，缺少分号等）
• [refactor]: 重构生产代码，例如重命名变量；既不是修复问题也不是新增功能
• [test]: 添加缺失的测试用例，重构测试用例；生产代码无变化
• [chore]: 更新构建工具等；生产代码无变化
• [bump]: 新版本

示例

单个提交示例

[feature](auth): 添加用户登录功能

- 实现登录表单及验证
- 添加 JWT token 处理
- 更新认证状态管理

[fix](api): 解决数据获取超时问题

- 修复连接超时配置
- 添加失败请求重试机制

[update](crowd-rule): 优化 disabled 模式下的显示逻辑

- 在 disabled 模式下，如果包含或排除没有数据，不展示对应的 group
- 如果包含和排除都没有数据，不展示整个 crowd-rule__content 区域

拆分提交示例

假设同时修改了用户登录功能和修复了 API 超时问题，应该拆分为两个提交：

提交 1：

[feature](auth): 添加用户登录功能

- 实现登录表单及验证
- 添加 JWT token 处理
- 更新认证状态管理

提交 2：

[fix](api): 解决数据获取超时问题

- 修复连接超时配置
- 添加失败请求重试机制

假设同时修改了代码和配置文件，应该拆分为两个提交：

提交 1：

[refactor](utils): 简化日期格式化逻辑

- 提取通用日期函数
- 提高代码可读性

提交 2：

[chore](vite): 切换代理目标到开发环境

- 将代理目标从测试环境切换到开发环境
- 注释掉测试环境 token 配置

注意事项

• 绝对禁止自动执行 git commit，必须获得用户的明确确认
• 必须先展示生成的 commit message，等待用户明确同意后再执行提交
• 如果用户未明确表示同意，任何情况下都不得执行 git commit 命令
• 执行提交前必须再次确认用户的明确意图
• 环境配置的修改（如 vite.config.ts 中的代理配置等）不要自动提交，直接忽略
• 自动识别并过滤常见的环境配置文件，包括但不限于：
  • vite.config.ts/js
  • webpack.config.js
  • .env 及其变体文件
  • 其他构建工具配置文件
• 严格区分提交类型，确保使用正确的类型：
  • [feature]：新功能
  • [fix]：bug 修复
  • [update]：功能优化、联调过程中的改进
  • [refactor]：代码重构
  • [chore]：构建工具、配置文件修改
• 如果变更复杂，可以提供多个 commit message 选项供用户选择
• commit message 使用中文描述
• subject 首字母自动小写，自动移除末尾句号
• scope 可选，如果提供会自动转换为小写
• 如果有破坏性变更，需要添加 BREAKING CHANGE 说明
• 每个提交应该只做一件事，保持提交的原子性
• 只要涉及多个功能点，就必须按功能拆分提交
• 如果变更涉及不同类型的修改，必须拆分提交
• 拆分提交时，使用 git add 选择性添加文件
• 如果用户明确要求合并提交，则以用户为准

技术实现细节

1. 环境配置文件识别：

   • 建立环境配置文件列表，包括常见的构建工具配置文件和环境变量文件
   • 在分析变更时，自动过滤这些文件的修改

2. 变更分析：

   • 执行 git diff --name-only 获取所有变更文件
   • 过滤掉环境配置文件
   • 对剩余文件进行分析，确定变更类型和范围

3. 提交计划生成：

   • 基于过滤后的变更文件生成提交计划
   • 确保环境配置文件的修改不会出现在提交计划中

4. 用户确认流程：

   • 展示生成的 commit message 和提交计划
   • 等待用户的明确确认
   • 只有在用户确认后才执行提交操作

5. 执行提交：

   • 使用 git add 选择性添加文件
   • 执行 git commit -m "message" 提交变更
   • 确保环境配置文件不会被添加到提交中

常见错误处理

1. 用户未确认直接提交：

   • 错误：在未获得用户明确确认的情况下执行 git commit 命令
   • 处理：必须严格遵守用户确认流程，先展示 commit message，等待用户确认后再执行提交

2. 提交类型选择错误：

   • 错误：将联调优化标记为 [fix]，或将 bug 修复标记为 [feature]
   • 处理：严格按照提交类型定义选择正确的类型，确保提交信息准确反映变更内容

3. 环境配置文件未过滤：

   • 错误：将 vite.config.ts 等环境配置文件的修改包含在提交计划中
   • 处理：自动识别并过滤环境配置文件，确保这些修改不会出现在提交计划中

4. 提交拆分不当：

   • 错误：将多个功能点或不同类型的修改合并在一个提交中
   • 处理：根据功能模块和变更类型拆分提交，保持提交的原子性

5. 用户确认后执行失败：

   • 错误：用户确认后执行 git commit 命令失败
   • 处理：检查错误信息，根据需要调整提交策略，确保提交成功