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