git-commit

name	git-commit
description	当用户要求提交代码、编写 commit message、执行 git commit/push/amend，或提到 提交、commit、推送、push、暂存并提交、保存更改、创建提交 时使用。

Git 代码提交

目标

按照步骤完成 Git 提交操作，且推送至远端仓库。

步骤

1. 检查当前 Git 仓库状态
2. 理解本次变更的真实意图
3. 判断是否存在不应提交的内容
4. 将变更组织成一个或多个逻辑提交
5. 编写高质量 Git 提交信息, 并且遵守下方的提交规范
6. 在确认安全后执行 git add 和 git commit

使用工具

以下是本内容使用到的一些工具，它们的格式为——<@工具名称>：

• <@交互式提问>：指宿主提供的、能发起单选/多选并等待用户回复的工具，不是固定名称。识别步骤：扫描当前会话可调用的工具清单；若任一工具语义命中「向用户提问 / 让用户选择 / 收集确认」，即视为命中并必须调用；完全无匹配时用一条简短文本问题暂停，禁止伪造工具调用。已知示例（不穷举）：AskQuestion、AskUserQuestion、request_user_input、question

步骤

1. 分析代码变更内容，理解变更意图
2. 判断变更是否包含敏感信息或不应提交的内容，并且使用 <交互式提问> 向用户确认
3. 将变更组织成一个或多个逻辑提交，不要把多个无关变更强行塞进一个提交
4. 按照 提交规范 编写高质量 Git 提交信息
5. 确认安全后执行 git add 和 git commit，完成提交操作
6. 使用 <@交互式提问> 工具询问用户是否需要推送到远端仓库，如果需要则执行 git push

提交规范

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

[可选的正文]

[可选的脚注]

核心规范

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

标题

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

正文

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

脚注

• 破坏性变更使用：

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

提交类型

类型	说明
feat	新功能
fix	Bug 修复
docs	文档变更
style	代码格式变更，不影响逻辑
refactor	重构，不新增功能也不修复 bug
perf	性能优化
test	测试相关
build	构建系统或依赖变更
ci	CI/CD 配置变更
chore	日常维护，杂项
revert	撤销提交