| name | git-commit |
| description | 当用户要求提交代码、编写 commit message、执行 git commit/push/amend,或提到 提交、commit、推送、push、暂存并提交、保存更改、创建提交 时使用。
|
Git 代码提交
目标
按照步骤完成 Git 提交操作,且推送至远端仓库。
步骤
- 检查当前 Git 仓库状态
- 理解本次变更的真实意图
- 判断是否存在不应提交的内容
- 将变更组织成一个或多个逻辑提交
- 编写高质量 Git 提交信息, 并且遵守下方的提交规范
- 在确认安全后执行
git add 和 git commit
使用工具
以下是本内容使用到的一些工具,它们的格式为——<@工具名称>:
- <@交互式提问>:指宿主提供的、能发起单选/多选并等待用户回复的工具,不是固定名称。识别步骤:扫描当前会话可调用的工具清单;若任一工具语义命中「向用户提问 / 让用户选择 / 收集确认」,即视为命中并必须调用;完全无匹配时用一条简短文本问题暂停,禁止伪造工具调用。已知示例(不穷举):
AskQuestion、AskUserQuestion、request_user_input、question
步骤
- 分析代码变更内容,理解变更意图
- 判断变更是否包含敏感信息或不应提交的内容,并且使用 <交互式提问> 向用户确认
- 将变更组织成一个或多个逻辑提交,不要把多个无关变更强行塞进一个提交
- 按照 提交规范 编写高质量 Git 提交信息
- 确认安全后执行
git add 和 git commit,完成提交操作
- 使用 <@交互式提问> 工具询问用户是否需要推送到远端仓库,如果需要则执行
git push
提交规范
<类型>(<范围>)!: <描述>
[可选的正文]
[可选的脚注]
核心规范
标题
- 使用祈使句或简洁动词短语
- 描述“做了什么”,避免空泛描述
- 尽量控制在 50 个字符以内
正文
- 解释为什么改,而不仅是改了什么
- 说明重要实现取舍
- 提及行为变化、兼容性影响、迁移事项
- 每行尽量不超过 72 字符
脚注
破坏性变更: <描述破坏性变更的内容>
提交类型
| 类型 | 说明 |
|---|
feat | 新功能 |
fix | Bug 修复 |
docs | 文档变更 |
style | 代码格式变更,不影响逻辑 |
refactor | 重构,不新增功能也不修复 bug |
perf | 性能优化 |
test | 测试相关 |
build | 构建系统或依赖变更 |
ci | CI/CD 配置变更 |
chore | 日常维护,杂项 |
revert | 撤销提交 |