git-commit-zh-split

name	git-commit-zh-split
description	当用户要求提交代码、整理提交、准备 commit、拆分 commit、push，或指定提交与推送规范时使用。默认使用中文提交信息，将差异较大的改动拆分为多个提交；推送前先执行 fetch、stash、rebase、stash pop，再 push。

中文提交并按变更拆分

当用户要求创建提交、整理提交、准备 commit、执行 push，或明确提到提交与推送规范时，使用这个 skill。

规则

• 除非用户明确要求其他语言，否则所有 commit message 都使用中文。
• 提交前先检查当前 diff，按变更意图和影响范围分组。
• 差异较大的改动要拆成多个 commit。
• 构建系统、配置、测试、重构、功能修改等不同类型的改动，能分开时就不要混在同一个 commit 里。
• 不要为了拆分而拆分，单个逻辑变更不能被切碎到多个 commit。
• 如果工作区里混有不该一起提交的用户改动，先停下来确认，不要擅自一起提交。
• 用户要求推送时，默认遵循固定流程：git fetch -> git stash -> git rebase -> git stash pop -> git push。
• 如果工作区本来就是干净的，可以跳过 stash 和 stash pop，但仍然要先 fetch 再 rebase。
• stash pop 后如果产生冲突，先解决冲突并确认工作区状态，再继续后续操作。

工作流

1. 运行 git status --short，并检查相关 diff。
2. 按用户可感知的目的、风险和作用范围决定提交边界。
3. 每次只暂存一组逻辑相关的改动。
4. 为每组改动创建一个中文 commit。
5. 全部提交完成后，再次运行 git status --short 确认工作区状态。

推送工作流

当用户要求 push、同步远端，或需要把本地提交推到远端时，按下面顺序执行：

1. 先运行 git fetch 同步远端引用。
2. 如果工作区有未提交改动，先 git stash 保存现场。
3. 基于对应远端分支执行 git rebase。
4. 如果前面做过 stash，在 rebase 完成后执行 git stash pop。
5. 如果 stash pop 或 rebase 产生冲突，先解决冲突并确认结果正确。
6. 工作区状态确认正常后，再执行 git push。

如果用户明确要求其他流程，再按用户要求执行；否则默认使用这套顺序。

提交信息要求

• 标题保持简洁，通常 8 到 20 个中文字符即可。
• 优先使用表意明确的动词开头，例如：修复、重构、调整、补充、优化。
• 需要时带上影响范围，例如：重构 cppOps 算子测试并补充性能基准。
• 不要把多个独立目的写进同一个标题。

向用户汇报时

• 按顺序列出本次创建的 commits。
• 如果拆成多个 commit，简要说明拆分依据。
• 如果有刻意未提交的本地修改，要明确说明。
• 如果执行了 push，简要说明是否经历了 stash、rebase、冲突处理，以及最终推送结果。