4.8 KiB
4.8 KiB
name, description
| name | description |
|---|---|
| commit-git-changes | 审查当前 Git 工作区，安全选择本次任务文件，生成包含问题背景、根因和修改方案的详细中文提交说明，并提交及按用户要求推送到 Git 服务器。默认不执行构建或测试；用户要求“提交代码”“提交并推送”“同步到 Git”“上传当前修改”或要求生成详细 commit message 时使用。 |
提交 Git 改动
目标
在不混入无关修改、不泄露敏感信息、不改写远端历史的前提下，完成“审查—暂存—提交—推送—确认”闭环，并用提交说明解释为什么修改以及如何解决，而不只是罗列文件。
工作流
- 读取仓库级
AGENTS.md、当前分支、远端和工作区状态。 - 检查暂存与未暂存差异：
- 使用
git status --short确认全部改动。 - 使用
git diff和git diff --cached理解真实行为变化。 - 必要时查看相关源码和测试，不能仅依据文件名编写提交说明。
- 使用
- 划定本次提交范围：
- 只纳入当前用户任务直接相关的文件。
- 保留用户已有或其他任务产生的无关修改。
- 优先显式
git add <path...>；仅在确认所有改动均属本次提交时使用git add -A。 - 发现密钥、令牌、证书、个人配置、大型生成物或疑似敏感数据时停止提交并说明。
- 不默认执行构建、测试或项目级验证；仅在用户明确要求时执行。
- 暂存后再次检查：
- 执行
git diff --cached --check。 - 执行
git diff --cached --stat和git diff --cached。 - 确认暂存区没有无关文件、调试残留和意外格式变化。
- 执行
- 编写详细中文提交说明并创建提交。
- 用户要求提交到服务器或同步远端时推送：
- 有 upstream 时推送当前分支。
- 没有 upstream 且远端、目标分支明确时，使用
git push -u <remote> <branch>。 - 远端或目标分支不明确时先询问，不猜测。
- 禁止 force push；除非用户明确要求且风险已说明。
- 提交后确认提交哈希、提交标题、当前分支、推送结果和剩余未提交改动。
提交说明规范
提交说明使用“标题 + 空行 + 详细正文”的结构。
标题
- 用一句中文概括用户可感知的问题和修复结果。
- 优先写清触发条件、异常表现和结果，例如：
修复无训练点普通课程完成后重进播放页回退为未完成 - 使用明确动词，如“修复”“新增”“调整”“重构”“移除”。
- 不使用“修改代码”“优化问题”“更新若干内容”等空泛描述。
- 保持单行，不以句号结尾，不添加无依据的工单号或模块前缀。
正文
用完整段落解释以下内容：
- 问题背景与影响：什么场景触发、用户看到什么、影响哪些路径。
- 根因：原有数据流、状态条件或实现约束为什么导致问题。
- 修改方案：关键行为如何改变，为什么选择该方案，必要时说明兼容和边界处理。
正文应描述行为和因果关系，不要把 git diff --stat 改写成文件清单。多个紧密相关的修改可以分段说明，但不要堆砌逐文件 bullet。
若用户明确要求并实际执行了构建、测试或其他验证，可以在正文末尾如实补充；未执行时不需要添加“验证：未执行”之类的说明。
示例
修复无训练点普通课程完成后重进播放页回退为未完成
课件完成态本地记录的保存不区分训练点，但读取端仅在存在
trainPointModel 时才创建合并器，导致班级、训练和项目均为空的普通课程
重进播放页后无法读取本地完成记录。
改为始终创建完成态合并器：无训练点时使用空维度合并；由于该场景没有
服务端完成态可供对账，将本地记录作为唯一持久来源并跳过超期回收，保持
重新进入播放页后的完成状态稳定。
根据真实改动改写示例内容，禁止照抄未发生的场景或验证结论。
提交与推送约束
- 不使用
git reset --hard、git checkout --、git clean等破坏性命令处理工作区。 - 不使用
--amend、rebase、历史改写或强制推送，除非用户明确授权。 - 不跳过 hooks；hook 失败时先分析原因，不使用
--no-verify绕过。 - 提交失败后保留暂存区，修复可控问题并重试；不要重复创建等价提交。
- 推送被拒绝时先获取并解释分支差异，不自动合并、变基或覆盖远端。
- 若没有可提交差异，直接说明，不创建空提交。
交付
报告提交哈希和标题、推送的远端分支，以及仍留在工作区的未提交修改。若只完成本地提交而未推送，必须明确说明。