---
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`、冲突处理，以及最终推送结果。