zhoujie
8cf3aff4e2
用户明确要求这个仓库的提交信息用中文;type前缀(feat/fix等)和scope仍保留 英文,分别对应社区通用约定和目录名本身。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4.7 KiB
4.7 KiB
name, description
| name | description |
|---|---|
| git-commit | Generate a Conventional-Commits-style message from the repo's current staged/unstaged changes and create the commit. Use whenever the user explicitly asks to commit, save, or checkpoint their work ("提交一下", "commit这些改动", "帮我提交代码", "存一下进度", "commit this"). Never invoke this proactively — only when the user asks for a commit, not merely after finishing an edit. Does not cover pushing, PR creation, amending, or any other git operation. |
Git 提交(规范化 commit message)
为什么需要这个技能
"提交一下"这句话背后其实有一套容易被跳过的步骤:先看清楚这次改动到底涉及
哪些文件、有没有不该进版本库的东西(密钥、临时文件、误生成的二进制),再把
分散的改动归纳成一句准确说明"为什么改"而不是"改了什么"的话——好的commit
message省的是未来翻git log时重新读一遍diff的时间。这个技能把这套步骤和
一套固定的message格式(Conventional Commits)定下来,避免每次现编、风格漂移。
工作流程
第一步:摸清这次改动的全貌
并行执行:
git status(不要加-uall,大仓库会有性能问题)git diff看未暂存的改动,git diff --cached看已暂存的改动git log --oneline -10看最近的提交,判断这个仓库习惯的message风格(有的仓库不用Conventional Commits前缀,这时候跟随仓库现有风格优先于本技能默认的格式)
第二步:提交前检查——发现问题就先说清楚,不要直接提交
逐条过一遍将要暂存的文件,确认没有:
- 明显的密钥/凭据文件(
.env、credentials.json、私钥等)——发现了就跳过并提醒用户,不要连带提交 - 不该进版本库的产物:打包导出的二进制(
.zip/.skill等)、编辑器/系统临时文件、体积异常大的文件 - 用
git add -A/git add .扫进来的、用户可能还不想提交的无关改动——按文件名显式git add,不要笼统全加
发现可疑内容,先列出来问用户怎么处理,不要自作主张排除或包含。
第三步:生成 commit message
message 正文(subject/body)用中文写——除非第一步发现这个仓库历史上明显
是用英文写(且不是本技能自己产生的commit),这种情况下跟随仓库现有语言。
type前缀本身仍用英文标准词(feat/fix等,这是社区通用约定,不翻译),
scope用原始的模块/skill名(通常本身就是英文目录名,不需要翻译)。
格式采用 Conventional Commits:
<type>(<scope>): <中文subject>
<中文body — 可选,只在"为什么"不是一眼能看出来的时候写>
type从改动的实际性质里选,不要凭感觉:feat(新功能)、fix(修bug)、refactor(不改行为的重构)、docs(纯文档)、test(测试)、chore(构建/ 依赖/杂项)、style(纯格式,不改逻辑)——一次提交只涉及一种性质就只写一个 type;如果改动明显跨性质(比如"顺手"把无关重构也塞进了这次提交),提醒用户 考虑拆成多个提交,而不是硬凑一个笼统的type。scope可选,涉及单一模块/skill时加上(比如literature-search-verify、paper-writing-grounded),改动横跨全仓库时省略。subject祈使/陈述语气均可、不超过~35个汉字、不以句号结尾,说清楚这次改动 做了什么,但真正的价值在于讲清楚为什么要这么改——如果"为什么"不是从 改动本身能一眼看出来的(比如修了一个不明显的bug、调整了一个非默认行为), 写进body里,不要只重复diff里已经能看到的内容。- 不要在message里提及和这次改动无关的历史背景或猜测性动机。
第四步:暂存并提交
- 按第二步筛选后的文件列表显式
git add <file1> <file2> ...,不要-A/. - 用 heredoc 传message,保证多行格式正确:
git commit -m "$(cat <<'EOF' <type>(<scope>): <subject> <body> EOF )" - 提交后跑一次
git status确认工作区状态符合预期
第五步:红线
- 只在用户明确要求提交时才创建commit,不要在完成一次编辑后主动提交
- 不新建commit时优先于
--amend——只有用户明确要求"修改上一个commit"才用amend,而且如果上一次是因为pre-commit hook失败而"没有真正提交成功",绝不能用--amend(那样会改到更早的一个commit) - 不加
--no-verify/--no-gpg-sign跳过hook或签名,除非用户明确要求;hook失败时先定位问题、修复后重新git add再建一个新commit - 不主动
git push,除非用户在这次请求里明确说了要推送 - 不做
reset --hard/checkout --/clean -f等破坏性操作来"顺手"清理提交前发现的问题,发现了就报告给用户决定