# Git Commit

> 使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。

- Skill: `zhinkgit/git-commit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zhinkgit/git-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhinkgit/git-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhinkgit (https://skillmd.com/u/zhinkgit)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhinkgit/git-commit

---


# Git Commit 中文提交助手

## 作用

当用户要求“提交一下”“commit”“创建 git commit”或使用 `/commit` 时，帮助完成一次安全、清晰、可追溯的 Git 提交。

核心目标：

- 只提交本次任务相关改动。
- 使用中文提交说明。
- 保留 Conventional Commits 的类型和作用域结构。
- 不覆盖、不回退、不混入用户已有改动。
- 提交失败时暴露真实错误并协助修复。

## 提交格式

优先使用单行中文 Conventional Commit：

```text
<type>(<scope>): <中文描述>
```

示例：

```text
fix(can): 修复 CAN7000 录波保存异常
docs(skills): 更新本地技能同步说明
chore(git): 调整提交助手规则
```

如果没有明确作用域，可以省略 `scope`：

```text
docs: 更新技能列表
```

## 类型选择

| 类型 | 使用场景 |
| --- | --- |
| `feat` | 新增用户可见功能 |
| `fix` | 修复缺陷、异常行为或回归 |
| `docs` | 仅文档、说明、注释类改动 |
| `style` | 格式、空白、排版等不影响逻辑的改动 |
| `refactor` | 既非新增功能也非修复缺陷的代码重构 |
| `perf` | 性能优化 |
| `test` | 新增或调整测试 |
| `build` | 构建系统、依赖、工程配置 |
| `ci` | CI/CD 配置 |
| `chore` | 维护性事务、脚本、工具配置 |
| `revert` | 回滚已有提交 |

## 工作流程

### 1. 检查仓库状态

先查看工作区状态和分支：

```bash
git status --short --branch
```

必须识别：

- 哪些文件是本次任务产生的。
- 哪些文件是用户原本已有的改动。
- 是否存在未跟踪文件、删除文件、子仓库改动或大范围无关变更。

如果工作区里有明显无关改动，不要全量暂存；只处理本次任务相关文件。

### 2. 分析 diff

如果已有暂存内容，优先分析暂存区：

```bash
git diff --staged
```

如果没有暂存内容，分析工作区改动：

```bash
git diff
```

需要判断：

- 改动目的是什么。
- 影响范围是什么。
- 是否应该拆成多个提交。
- 是否包含密钥、Token、私钥、`.env`、真实服务器密码等敏感信息。

### 3. 谨慎暂存

只暂存与本次提交直接相关的文件：

```bash
git add path/to/file1 path/to/file2
```

禁止为了省事执行无差别暂存：

```bash
git add .
git add -A
```

除非用户明确要求“提交全部改动”，否则不要使用全量暂存。

对于大型混合改动，优先建议拆分提交；如果必须从同一文件里挑选部分改动，可以使用交互式暂存：

```bash
git add -p
```

但在自动化环境中，优先采用明确文件路径暂存，避免进入交互式流程。

### 4. 生成中文提交信息

提交描述应满足：

- 使用中文。
- 简洁说明“做了什么”，不要写空泛词。
- 首行尽量不超过 72 个字符。
- 类型和作用域与实际 diff 对齐。
- 不夸大影响范围，不写未完成事项。

优先从文件路径、模块名、功能点推断 `scope`。例如：

- `sync-agent-skills.ps1` -> `skills`
- `embeddedskills/can/*` -> `can`
- `embeddedskills/gcc/*` -> `gcc`
- `normalskills/git-commit/*` -> `git`

### 5. 执行提交

单行提交：

```bash
git commit -m "type(scope): 中文描述"
```

需要补充正文时，使用多条 `-m`：

```bash
git commit -m "type(scope): 中文描述" -m "补充说明改动背景、验证结果或兼容性影响。"
```

提交后读取结果，向用户说明：

- 提交 hash。
- 提交信息。
- 是否还有未提交改动。
- 是否有未纳入提交的用户改动。

## 多仓库规则

如果当前任务同时修改了多个独立 Git 仓库，应分仓提交。

每个仓库都要单独执行：

```bash
git status --short --branch
git diff
git add <相关文件>
git commit -m "type(scope): 中文描述"
```

不要跨仓库混淆提交结果。最终回复要分别列出每个仓库的提交 hash。

## 安全规则

- 不修改 Git 全局配置。
- 不执行 `git reset --hard`、`git checkout -- <path>` 等会丢弃改动的命令，除非用户明确要求。
- 不使用 `--force`、`--force-with-lease` 推送，除非用户明确要求。
- 不使用 `--no-verify` 跳过 hook，除非用户明确要求。
- 不 amend 已有提交，除非用户明确要求。
- 不提交密钥、Token、私钥、真实密码或本地敏感配置。
- 不为了让提交通过而删除测试、吞掉错误或隐藏失败信息。

## 失败处理

如果提交失败：

1. 保留真实错误输出。
2. 判断是 hook、格式检查、冲突、权限、路径编码还是 Git 状态问题。
3. 优先修复根因后重新提交。
4. 不要绕过校验，除非用户明确要求。

如果发现当前状态不适合提交，例如无关改动过多、敏感文件已暂存、仓库处于 rebase/merge 冲突中，应先停止并说明原因。