# Git Commit Message

> Use in any Git repository after code changes, or when the user asks to generate commit text / commit message / commit 文案 / 写个commit, to inspect real diffs and the current git user's own commit history, then produce a scoped multi-line commit message without staging or committing unless explicitly requested.

- Skill: `xfcycc/git-commit-message` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add xfcycc/git-commit-message`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xfcycc/git-commit-message/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: xfcycc (https://skillmd.com/u/xfcycc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/xfcycc/git-commit-message

---


# Git Commit Message

用于任意 Git 项目里“改完代码后生成 commit 文案”的通用流程。

## 触发场景

- 已完成一次代码改动，需要在最终回复里附上 commit message。
- 用户说“写个commit”“生成commit文案”“commit message”“参考历史提交记录格式”。
- 用户只要文案时，只输出文案；不要顺手执行 `git add` 或 `git commit`。

## 基本约束

- 默认只生成 commit 文案，不暂存、不提交。
- 只有用户明确要求提交时，才执行 `git add` / `git commit`。
- 优先匹配用户语言；中文对话默认输出中文 commit 文案。
- 只参考当前 git 用户自己的提交记录，不用其他作者的提交作为格式样板。
- 每条文案只覆盖本次任务实际触达的改动；忽略无关历史脏改。
- 多仓库或多主题改动要分别生成，不要硬塞进一条。

## 工作流

### 1. 找到真实 Git 仓库

先确认当前目录是否在 Git 仓库中：

```bash
git rev-parse --show-toplevel
git status --short
git diff --stat
git diff --cached --stat
```

如果当前目录不是仓库根，进入 `git rev-parse --show-toplevel` 返回的根目录继续检查。

如果是多仓库工作区，优先检查：

- 本轮编辑过的文件所在仓库。
- 当前目录下一层或两层内包含 `.git` 的子仓库。
- 用户明确点名的仓库。

对每个候选仓库读取：

```bash
git -C <repo> status --short
git -C <repo> diff --stat
git -C <repo> diff --cached --stat
```

只为有本次相关改动的仓库生成文案。遇到无关改动，说明已忽略。

### 2. 读取当前用户历史格式

确认当前仓库的 git 身份：

```bash
git -C <repo> config user.name
git -C <repo> config user.email
```

只读取当前用户自己的近期完整提交信息：

```bash
git -C <repo> log -10 --author="<user.name>" --pretty=format:'%B%n---END---'
git -C <repo> log -10 --author="<user.email>" --pretty=format:'%B%n---END---'
```

使用规则：

- 优先参考当前仓库中能查到记录的本地 author。
- 如果 name 和 email 查到的结果不同，合并去重后参考。
- 忽略 merge、WIP、临时提交、乱码、明显不完整提交。
- 重点参考完整格式：标题、scope、空行、正文分点，而不只看标题。
- 如果当前用户没有提交样本，说明这一点，再使用项目通用约定。

### 3. 基于真实 diff 写文案

必要时读取关键 diff，而不是只看文件名：

```bash
git -C <repo> diff -- <path>
git -C <repo> diff --cached -- <path>
```

默认输出“标题 + 空行 + 分点正文”的完整文案：

```text
fix(scope): 中文说明

- 说明第一个真实改动点
- 说明第二个真实改动点
- 说明兼容、校验、兜底或验证闭环
```

类型选择：

- `fix`: 修复 bug、纠正异常行为、补兼容。
- `feat`: 新增功能、接口字段、页面能力。
- `style`: 仅 UI 样式、展示文案或格式调整。
- `docs`: 文档变更。
- `refactor`: 行为不变的结构调整。
- `test`: 测试相关。
- `chore`: 构建、配置、脚手架、依赖等杂项。

scope 规则：

- 优先取真实业务模块、页面、包名、服务名或目录名。
- 如果历史提交有稳定 scope 风格，跟随历史。
- 不确定 scope 时可以省略，不要编造不存在的模块名。

文案风格：

- 标题简洁描述结果，不写句号。
- 标题和正文之间保留一个空行。
- 正文使用 `- ` 分点，每条只写一个真实改动点。
- 分点数量按实际改动决定，通常 2 到 5 条。
- 不用“优化”兜底，除非实际就是体验、性能或结构优化。
- 不夸大范围，不把局部修复写成整体重构。

### 4. 最终输出

如果本轮完成了代码改动，最终回复里在验证结果后补：

```text
commit文案：
fix(scope): 中文说明

- ...
- ...
```

多仓库时标明仓库名：

```text
<repo>:
fix(scope): 中文说明

- ...
```

如果用户只要 commit 文案，直接输出文案即可，不额外解释。