Git Commit

Git 代码提交

独立工具技能。谁调用都可以。何时提交、交哪些文件、提交信息要点由调用方给出；本技能只负责怎么提交。

目标

按模式完成 Git 提交。交互模式可再问是否 push；auto 模式只做本地提交。

模式

• 交互（默认）：用户显式要求提交或推送。
• auto：调用方指定 auto。本地 git add + git commit，禁止 push，禁止问要不要推送。

统一工具定义

• 交互式提问：大部分 Agent 都内置的一种工具, 由 Agent 向用户提出问题并提供选项和自定义输入的一种工具, 它在不同的 Agent 中的名称不同, 可能叫 AskUserQuestion 或 AskQuestion 等。auto 模式不要用它问是否 push。

交互模式

1. 检查 git status / git diff / git log，理解变更意图。
2. 判断是否包含密钥或不应提交的内容，使用 交互式提问 工具来向用户确认。
3. 将变更组织成一个或多个逻辑提交，不要把无关变更塞进一个提交。
4. 按 提交规范 写中文提交信息。
5. 确认安全后 git add 和 git commit。不要 --no-verify。
6. 使用 交互式提问 工具来问是否 push；需要才 git push。

auto 模式

1. git status：没有已跟踪变更且没有应入库的新文件 → 汇报「无提交」，结束。
2. 发现 .env、密钥、凭证、明显不该入库的文件 → 停止，不要提交，列给用户。不要用提问把风险问过去。
3. 暂存范围：调用方指定了路径则只暂存这些路径；未指定则只暂存本轮应入库文件。不要顺手塞进无关脏文件。不要强制 add 已被 gitignore 的路径。
4. 一个逻辑提交；按 提交规范 写中文信息。调用方给了提交信息要点则采用，否则按实际 diff 写。
5. git add 指定路径 + git commit。不要 --no-verify。不要 git push。
6. 汇报 commit hash，并写明未推送。

提交规范

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

[可选的正文]

[可选的脚注]

核心规范

• 必须使用中文编写提交信息

标题

• 使用祈使句或简洁动词短语
• 描述“做了什么”，避免空泛描述
• 尽量控制在 50 个字符以内

正文

• 解释为什么改，而不仅是改了什么
• 说明重要实现取舍
• 提及行为变化、兼容性影响、迁移事项
• 每行尽量不超过 72 字符

脚注

破坏性变更使用：

破坏性变更: <描述破坏性变更的内容>

提交类型