xfcycc 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 仓库中：
git rev-parse --show-toplevel
git status --short
git diff --stat
git diff --cached --stat
如果当前目录不是仓库根，进入 git rev-parse --show-toplevel 返回的根目录继续检查。
如果是多仓库工作区，优先检查：
- 本轮编辑过的文件所在仓库。
- 当前目录下一层或两层内包含
.git的子仓库。 - 用户明确点名的仓库。
对每个候选仓库读取：
git -C <repo> status --short
git -C <repo> diff --stat
git -C <repo> diff --cached --stat
只为有本次相关改动的仓库生成文案。遇到无关改动，说明已忽略。
2. 读取当前用户历史格式
确认当前仓库的 git 身份：
git -C <repo> config user.name
git -C <repo> config user.email
只读取当前用户自己的近期完整提交信息：
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，而不是只看文件名：
git -C <repo> diff -- <path>
git -C <repo> diff --cached -- <path>
默认输出“标题 + 空行 + 分点正文”的完整文案：
fix(scope): 中文说明
- 说明第一个真实改动点
- 说明第二个真实改动点
- 说明兼容、校验、兜底或验证闭环
类型选择：
fix: 修复 bug、纠正异常行为、补兼容。feat: 新增功能、接口字段、页面能力。style: 仅 UI 样式、展示文案或格式调整。docs: 文档变更。refactor: 行为不变的结构调整。test: 测试相关。chore: 构建、配置、脚手架、依赖等杂项。
scope 规则：
- 优先取真实业务模块、页面、包名、服务名或目录名。
- 如果历史提交有稳定 scope 风格，跟随历史。
- 不确定 scope 时可以省略，不要编造不存在的模块名。
文案风格：
- 标题简洁描述结果，不写句号。
- 标题和正文之间保留一个空行。
- 正文使用
-分点，每条只写一个真实改动点。 - 分点数量按实际改动决定，通常 2 到 5 条。
- 不用“优化”兜底，除非实际就是体验、性能或结构优化。
- 不夸大范围，不把局部修复写成整体重构。
4. 最终输出
如果本轮完成了代码改动，最终回复里在验证结果后补：
commit文案：
fix(scope): 中文说明
- ...
- ...
多仓库时标明仓库名：
<repo>:
fix(scope): 中文说明
- ...
如果用户只要 commit 文案，直接输出文案即可，不额外解释。