Git Commit

来源说明

该技能本质上是参考 agent-toolkit/skills/commit-work 文档的纯中文翻译版本，并进行了特定改写以适应当前环境。

目标

制作易于审查且安全发布的提交：

• •仅包含预期的变更
• •提交具有逻辑范围（必要时进行拆分）
• •提交信息描述了变更内容和原因

需要询问的输入（如果缺失）

• •单个提交还是多个提交？（如果不确定：当存在不相关的变更时，默认为多个小提交。）
• •提交风格：必须使用 Conventional Commits，并包含 Emoji。
• •任何规则：最大标题长度，必需的作用域。

工作流程（清单）

1. •在暂存前检查工作树
   • •git status
   • •git diff (未暂存)
   • •如果变更较多：git diff --stat
2. •决定提交边界（必要时拆分）
   • •拆分依据：功能 vs 重构，后端 vs 前端，格式化 vs 逻辑，测试 vs 生产代码，依赖升级 vs 行为变更。
   • •如果变更混合在一个文件中，计划使用补丁暂存 (patch staging)。
3. •仅暂存属于下一个提交的内容
   • •对于混合变更首选补丁暂存：git add -p
   • •取消暂存块/文件：git restore --staged -p 或 git restore --staged <path>
4. •审查实际将要提交的内容
   • •git diff --cached
   • •合规性检查：
     • •无密钥或令牌
     • •无意外的调试日志
     • •无不相关的格式化变动
5. •用 1-2 句话描述暂存的变更（在编写信息之前）
   • •"变更了什么？" + "为什么？"
   • •如果你无法清晰地描述它，那么提交可能太大或混合了；返回第 2 步。
6. •编写提交信息
   • •必须使用中文编写提交信息。
   • •使用 Conventional Commits（必需）：
     • •<emoji> type(scope): short summary
     • •(空行)
     • •body (内容/原因，而非实现流水账)
     • •footer (BREAKING CHANGE) 如果需要
   • •Emoji 和 Type 规范：必须查阅并遵循 commit-types.ts 中的定义。
     • •主动查阅：使用 Read 或 WebFetch 工具主动读取上述文件以获取最新的 Emoji 和 Type 列表。
   • •对于多行信息首选编辑器：git commit -v
   • •参考 references/commit-message-template.md 获取完整的模板和 Emoji 列表。
7. •运行最小的相关验证
   • •在继续之前运行仓库中最快且有意义的检查（单元测试、lint 或构建）。
8. •重复下一个提交，直到工作树干净

交付物

提供：

• •最终的提交信息（包含 Emoji，中文编写）
• •每个提交的简短摘要（内容/原因）
• •用于暂存/审查的命令（至少：git diff --cached，加上运行的任何测试）