Git 提交与推送工作流
此技能提供规范化的 git 提交与推送流程。根据用户意图，自动分析代码变更、生成规范提交信息，并执行提交和/或推送操作。
核心流程
第一步：识别用户意图
分析用户请求，确定需要执行的操作：
| 意图 | 触发词示例 | 执行动作 |
|---|---|---|
| 仅提交 | "提交代码"、"commit" | 执行第二至五步 |
| 仅推送 | "推送代码"、"push"、"推上去" | 仅执行第六步 |
| 提交并推送 | "提交并推送"、"commit and push" | 执行全部步骤 |
支持组合执行——根据用户实际需求灵活选择执行哪些步骤。
第二步：检查并查看变更内容
运行 git status 和 git diff（含已暂存和未暂存的变更），获取当前工作区的完整变更状态。
如果没有任何变更（工作区干净）：
- 提示用户当前无变更内容，终止流程
- 示例提示："当前工作区没有需要提交的变更。"
如果存在变更： 继续下一步。
第三步：分析变更并总结内容
仔细阅读所有变更的 diff 内容，按以下维度总结：
- 新增功能：新增了 xx 功能/模块/文件
- 功能修改：修改了 xx 功能的 yy 行为
- 问题修复：修复了 xx 问题，当 aa 时，应该 bb
- 代码重构：重构了 xx 模块，影响范围包括 1. xx, 2. yy
- 文档变更：更新了 xx 文档/注释
- 配置变更：修改了 xx 配置文件
- 测试变更：新增/修改了 xx 测试用例
总结应简明扼要，突出关键变更点。
第四步：确定提交类型
根据变更内容总结，选择最匹配的提交类型：
| 类型 | 适用场景 | 示例 |
|---|---|---|
feat | 新增功能或功能性修改 | 新增用户登录功能 |
fix | 问题修复 | 修复列表页分页异常 |
docs | 文档变更（README、注释等） | 更新 API 文档 |
refactor | 代码重构（不改变功能） | 重构数据访问层 |
chore | 配置/工具链变更 | 更新 ESLint 配置 |
test | 测试相关变更 | 新增单元测试 |
style | 代码格式调整（不影响逻辑） | 统一缩进风格 |
perf | 性能优化 | 优化列表渲染性能 |
ci | CI/CD 相关变更 | 更新 GitHub Actions 配置 |
misc | 混合类型/无法归类（尽量避免） | 多项不相关改动 |
选择原则： 以变更的主要目的为准。若变更涉及多种类型且无法明确主要目的，使用 misc，但应建议用户将变更拆分为多次提交。
第五步：生成提交信息并执行提交
提交信息格式
<type>[(scope)]: <message>
<body>
---
Co-authored-by: <model_name> <email>
各部分说明：
- type：第四步确定的提交类型
- scope（可选）：主要涉及的修改对象
- 组件相关 →
(components) - 某功能模块 →
(模块名) - 多个模块 → 可省略 scope
- 示例：
(auth)、(ui)、(api)、(config)
- 组件相关 →
- message：一句话总结变更内容，不超过 15 个字
- body：详细描述本次变更的内容，基于第三步的分析结果，列出关键变更点。每个要点独占一行，使用
-前缀 - Co-authored-by：标注 AI 协作者信息，以
---分隔线与主体隔开。根据当前 agent 自动填充签名（见下方签名映射表）
Co-authored-by 签名映射
根据当前运行的 AI agent 自动选择对应的签名：
| Agent | 签名 |
|---|---|
| Claude | Co-authored-by: claude-4.5-sonnet <noreply@anthropic.com> |
| Gemini | Co-authored-by: gemini-3-pro <noreply@google.com> |
填充规则：
- 签名格式：
Co-authored-by: <model_name> <email> model_name：当前 agent 使用的模型名称（如claude-4.5-sonnet、gemini-3-pro）email：对应厂商的 noreply 邮箱- 如果无法识别当前 agent，默认使用
ai-assistant <noreply@example.com>
提交信息示例
feat(auth): 新增用户登录功能
- 新增 LoginForm 组件，支持用户名/密码登录
- 新增 auth 模块，封装登录/登出/Token 刷新逻辑
- 新增登录页路由配置
---
Co-authored-by: <model_name> <email>
fix(list): 修复分页数据加载异常
- 修复分页参数未正确传递导致的数据重复加载问题
- 修正页码从 0 开始的偏移错误
---
Co-authored-by: <model_name> <email>
docs: 更新 API 接口文档
- 补充用户模块接口的请求/响应示例
- 更新认证相关接口的参数说明
---
Co-authored-by: <model_name> <email>
执行提交
- 使用
git add将相关文件添加到暂存区（优先添加具体文件，避免使用git add .） - 由于提交信息包含多行内容，使用 HEREDOC 方式传递提交信息：
git commit -m "$(cat <<'EOF' <type>[(scope)]: <message> <body> --- Co-authored-by: <model_name> <email> EOF )" - 如果提交因 git hook 失败，禁止使用
--no-verify跳过验证，立即停止流程并告知用户具体的 hook 错误信息 - 确认提交成功后，向用户展示提交结果
第六步：执行推送（如需要）
根据第一步识别的意图，如果需要推送：
- 使用
git push推送到远程仓库 - 如果当前分支没有上游分支，使用
git push -u origin <branch-name> - 检查推送命令的返回输出：
- 如果输出中包含创建 Pull Request 的链接：提示用户可以通过该链接创建 Pull Request
- 如果输出中包含已有 Pull Request 的链接：提示用户可以通过该链接查看 Pull Request
- 如果没有返回任何链接：不做额外提示，仅确认推送成功
注意事项
- 提交前确认变更文件中不包含敏感信息（如
.env、密钥文件等） - 如果发现可能的敏感文件，警告用户并等待确认
- 如果提交因 git hook（pre-commit、commit-msg 等）失败，严禁使用
--no-verify参数跳过 hook 验证。 应立即停止提交流程，将 hook 输出的错误信息完整地告知用户，由用户自行决定后续处理方式 - 推送失败时，分析错误原因并给出解决建议
- 若遇到网络错误，最多重试 4 次，采用指数退避策略（2s、4s、8s、16s）
- 整个流程中使用中文与用户交互