Git Commit with Conventional Commits
概述
使用 Conventional Commits 规范创建标准化、语义化的 git 提交。通过分析实际的 diff 来确定合适的类型（type）、范围（scope）和消息内容。
约定式提交格式
<类型>[可选 范围]: <描述>
[可选 正文]
[可选 页脚]
提交类型
| 类型 | 用途 |
|---|---|
feat | 新特性 |
fix | 修复 bug |
docs | 仅文档变更 |
style | 格式/风格调整（不涉及逻辑变化） |
refactor | 代码重构（非新特性或修复 bug） |
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. 分析 Diff
# 如果有暂存的更改，使用暂存 diff
git diff --staged
# 如果没有暂存文件，使用工作区 diff
git diff
# 同时检查状态
git status --porcelain
2. 暂存文件（如果需要）
如果没有暂存文件，或你想以不同方式分组更改：
# 暂存特定文件
git add path/to/file1 path/to/file2
# 按模式暂存
git add *.test.*
git add src/components/*
# 交互式暂存
git add -p
切勿提交敏感信息（.env、credentials.json、私钥等）。
3. 生成提交消息
提交消息必须严格只用英文编写——包括主题行和正文。即使仓库历史中有俄文提交，也绝不要用俄文写提交消息。
分析 diff 以确定：
- 类型：此次变更是哪种类型？
- 范围：影响哪个领域/模块？
- 描述：变更内容的一行摘要（使用现在时、祈使语气，不超过 72 个字符）
4. 执行提交
# 单行提交
git commit -m "<类型>[范围]: <描述>"
# 多行提交（包含正文/页脚）
git commit -m "$(cat <<'EOF'
<类型>[范围]: <描述>
<可选 正文>
<可选 页脚>
EOF
)"
最佳实践
- 提交消息严格只用英文编写（包括主题行和正文）
- 每个提交只做一种逻辑更改
- 使用现在时：“add”而非“added”
- 使用祈使语气：“fix bug”而非“fixes bug”
- 引用 issue：
Closes #123、Refs #456 - 描述控制在 72 个字符以内
Git 安全协议
- 绝不要修改 git 配置
- 未经明确请求，绝不运行破坏性命令（--force、hard reset）
- 除非用户要求，绝不跳过钩子（--no-verify）
- 绝不要强制推送到 main/master 分支
- 如果因钩子失败，则修复问题并创建新的提交（不要修改）
- 未经用户明确询问，绝不创建新分支。
直接提交到当前分支（包括
main），除非用户要求创建分支。不要为了“安全”而自动创建分支——用户自行管理分支策略。如果你认为有必要创建分支，必须先征求用户同意。 - 除非用户要求，绝不要推送到新的远程分支或创建 MR/PR。