Git Committer
这个 skill 帮助分析 git 变更内容并生成符合项目规范的 commit message。
何时使用
当用户出现以下情况时调用此 skill：
- 用户说"提交代码"、"commit"、"生成 commit message"
- 用户需要将当前的代码变更提交到 git 仓库
- 用户想要查看变更并生成提交信息
- 用户执行 git 相关操作时
工作流程
- 查看 git 状态
- 执行 git status 查看当前变更状态 - 执行 git diff 查看未暂存的变更 - 执行 git diff --cached 查看已暂存的变更
- 环境配置文件过滤
- 自动识别并过滤环境配置文件的修改 - 常见的环境配置文件包括： - vite.config.ts/js - webpack.config.js - .env 及其变体文件 - 其他构建工具配置文件 - 这些文件的修改不会生成提交计划，直接忽略
- 分析变更内容
- 识别变更的文件类型和影响范围 - 理解变更的目的和功能 - 确定变更的类型（[feature]、[fix]、[update]、[docs]、[style]、[refactor]、[test]、[chore]、[bump] 等）
- 判断是否需要拆分提交
- 如果变更涉及多个功能点，必须按功能拆分提交 - 如果变更涉及不同类型的修改（如同时有新功能和 bug 修复），必须拆分提交 - 每个提交应该只做一件事，保持提交的原子性
- 拆分提交策略
- 按功能模块拆分：将同一功能相关的文件归为一组 - 按变更类型拆分：将新功能、bug 修复、重构等分开提交 - 按文件类型拆分：将代码变更、配置变更、文档变更分开提交 - 每次提交前使用 git add 添加对应的文件，然后提交
- 生成 commit message
- 遵循项目使用的方括号格式规范 - 格式：[type](scope): subject - subject 使用中文描述，首字母小写，不以句号结尾 - 包含简洁的描述和必要的详细说明 - 如果有相关 issue，添加引用 - 标题最大宽度 100 字符
- 用户确认流程
- 必须先展示生成的 commit message 和提交计划，等待用户明确同意后再执行提交 - 只有在用户明确确认后，才能执行 git commit -m "message" - 绝对禁止在未获得用户明确确认的情况下自动执行 git commit 命令 - 必须在展示 commit message 后等待用户的明确回应，如"确认"、"可以"、"同意"等 - 如果用户对 commit message 提出修改意见，必须根据用户意见调整后重新展示并等待确认 - 如果需要拆分提交，必须为每个提交单独获得用户确认 - 如果用户明确要求合并提交，则以用户为准
- 执行提交
- 根据用户确认的提交计划执行提交操作 - 使用 git add 选择性添加文件 - 执行 git commit -m "message" 提交变更 - 确保环境配置文件不会被添加到提交中
- 推送代码（可选）
- 所有提交完成后，询问用户是否需要推送代码 - 如果用户需要推送，调用 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选择性添加文件 - 如果用户明确要求合并提交，则以用户为准
技术实现细节
- 环境配置文件识别：
- 建立环境配置文件列表，包括常见的构建工具配置文件和环境变量文件 - 在分析变更时，自动过滤这些文件的修改
- 变更分析：
- 执行 git diff --name-only 获取所有变更文件 - 过滤掉环境配置文件 - 对剩余文件进行分析，确定变更类型和范围
- 提交计划生成：
- 基于过滤后的变更文件生成提交计划 - 确保环境配置文件的修改不会出现在提交计划中
- 用户确认流程：
- 展示生成的 commit message 和提交计划 - 等待用户的明确确认 - 只有在用户确认后才执行提交操作
- 执行提交：
- 使用 git add 选择性添加文件 - 执行 git commit -m "message" 提交变更 - 确保环境配置文件不会被添加到提交中
常见错误处理
- 用户未确认直接提交：
- 错误：在未获得用户明确确认的情况下执行 git commit 命令 - 处理：必须严格遵守用户确认流程，先展示 commit message，等待用户确认后再执行提交
- 提交类型选择错误：
- 错误：将联调优化标记为 [fix]，或将 bug 修复标记为 [feature] - 处理：严格按照提交类型定义选择正确的类型，确保提交信息准确反映变更内容
- 环境配置文件未过滤：
- 错误：将 vite.config.ts 等环境配置文件的修改包含在提交计划中 - 处理：自动识别并过滤环境配置文件，确保这些修改不会出现在提交计划中
- 提交拆分不当：
- 错误：将多个功能点或不同类型的修改合并在一个提交中 - 处理：根据功能模块和变更类型拆分提交，保持提交的原子性
- 用户确认后执行失败：
- 错误：用户确认后执行 git commit 命令失败 - 处理：检查错误信息，根据需要调整提交策略，确保提交成功