关于 git-commit
面向需要提交 Git 变更的开发者，提供按 Conventional Commits 规范生成提交信息的流程。指南要求检查实际差异，并按变更类型、范围和内容组织提交。
主要功能
- 01检查状态并确定提交范围
- 02分析暂存区或工作区差异
- 03按 Conventional Commits 选择类型
- 04按需处理破坏性变更标记
- 05提交后检查状态与记录
适用场景
- 01为新功能或修复撰写规范提交信息
- 02仅提交暂存的逻辑变更
- 03区分文档、测试和构建类提交
- 04核实提交后的工作区状态
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/git-commit确认已加载。
附带文件references/conventional-commits.md
详细介绍
使用 Conventional Commits 编写 Git 提交
使用 Conventional Commits 规范创建标准化的语义化 Git 提交。分析实际差异，确定合适的类型、范围和说明。
提交格式
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
提交类型
| 类型 | 用途 |
|---|---|
feat | 新功能 |
fix | 修复 Bug |
docs | 仅修改文档 |
style | 格式或样式调整（不涉及逻辑） |
refactor | 代码重构（不涉及新功能或修复） |
perf | 性能改进 |
test | 添加或更新测试 |
build | 构建系统或依赖项 |
ci | CI 或配置变更 |
chore | 维护或其他杂项 |
revert | 回退提交 |
破坏性变更
在类型或范围后加感叹号：
feat!: remove deprecated endpoint
和／或：添加 BREAKING CHANGE 页脚
feat: allow config to extend other configs
BREAKING CHANGE: `extends` key behavior changed
工作流
1. 检查状态
git status --porcelain
默认行为：
- 如果已有暂存的变更，优先使用这些变更。
- 如果没有暂存内容，只暂存逻辑上连贯的变更。
- 不要动与提交无关的工作区变更。
2. 分析差异
# If files are staged, use staged diff.
git diff --staged
# If nothing is staged, use working tree diff.
git diff
暂存和未暂存的变更并存时，默认只提交已暂存的变更。如果已暂存的变更似乎不完整，请检查未暂存的差异，并决定是否暂存密切相关的文件，或询问用户。
3. 暂存文件（如有需要）
如果没有已暂存的内容，或者想以不同方式分组变更：
# Stage specific files
git add path/to/file1 path/to/file2
# Stage by pattern
git add *.test.*
git add src/components/*
绝不要提交机密信息（.env、credentials.json、私钥）。
4. 生成提交说明
分析差异以确定：
- 类型：这是什么类型的变更？
- 范围：影响了哪个区域／模块？
- 说明：用一行概述变更内容。（使用现在时、祈使语气，少于 72 个字符）
使用最小但准确的类型和范围。优先选择简短的单行提交，不附正文。只有当提交规模较大或内容足够复杂，无法用一句简短的话清楚概括时，才添加正文。不要仅仅因为有额外背景信息就添加说明性正文。
只有当差异确实改变了公共契约时，才使用破坏性变更语法。
5. 执行提交
# Single line
git commit -m "<type>[scope]: <description>"
# Multi-line with body/footer
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
<optional body>
<optional footer>
EOF
)"
最佳实践
- 每个提交只包含一个逻辑变更。
- 使用现在时：用 “add”，不要用 “added”。
- 使用祈使语气：用 “fix bug”，不要用 “fixes bug”。
- 说明控制在 72 个字符以内。
- 只有当差异或用户请求提供了相关背景时，才使用
Closes #123或Refs #456等尾注引用问题。如果没有正文，则将其追加在说明后：feat: add login, closes #123。
Git 安全协议
- 绝不要更新 Git 配置。
- 未经明确请求，绝不要运行破坏性命令（
--force、硬重置）。 - 除非用户提出要求，否则绝不要跳过钩子（
--no-verify）。 - 绝不要强制推送到 main/master。
- 如果钩子在创建提交前失败，请修复问题后重试。
- 如果提交已创建，但后续验证失败，除非用户提出要求，否则不要 amend。
最终验证
提交后：
git status --short
git log -1 --oneline
报告新提交的哈希和主题。说明是否还有未暂存或未跟踪的变更。
参考资料
评论
支持 Markdown