git-commit
使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。
ソース情報
- リポジトリ
- zhinkgit/normalskills
- ソースの最終更新活動
- 2026年5月25日 07:40
- 検出された SKILL.md の言語
- 中国語
- スター
- 1
- フォーク
- 1
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SKILL.md を表示中
SKILL.md
ソースの指示 · 読み取り専用プレビュー- name
- git-commit
- description
- 使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 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 冲突中，应先停止并说明原因。
GitHubで見る