Back to Details

git-commit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Git Commit with Conventional Commits

遵循Conventional Commits规范的Git提交

Overview

概述

Create standardized, semantic git commits using the Conventional Commits specification. Analyze the actual diff to determine appropriate type, scope, and message.
使用Conventional Commits规范创建标准化的语义化git提交。分析实际的diff以确定合适的类型、范围和消息。

Conventional Commit Format

规范提交格式

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
<type>[可选范围]: <描述>

[可选正文]

[可选页脚]

Commit Types

提交类型

TypePurpose
feat
New feature
fix
Bug fix
docs
Documentation only
style
Formatting/style (no logic)
refactor
Code refactor (no feature/fix)
perf
Performance improvement
test
Add/update tests
build
Build system/dependencies
ci
CI/config changes
chore
Maintenance/misc
revert
Revert commit
类型用途
feat
新功能
fix
修复Bug
docs
仅修改文档
style
格式/样式调整（无逻辑变更）
refactor
代码重构（无新功能/修复）
perf
性能优化
test
添加/更新测试
build
构建系统/依赖变更
ci
CI/配置变更
chore
维护/杂项
revert
回退提交

Breaking Changes

重大变更

undefined
undefined

Exclamation mark after type/scope

在类型/范围后添加感叹号

feat!: remove deprecated endpoint
feat!: 移除已弃用的端点

BREAKING CHANGE footer

使用BREAKING CHANGE页脚

feat: allow config to extend other configs
BREAKING CHANGE: 
extends
key behavior changed
undefined
feat: 允许配置继承其他配置
BREAKING CHANGE: 
extends
键的行为已变更
undefined

Workflow

工作流程

1. Analyze Diff

1. 分析Diff

bash
undefined
bash
undefined

If files are staged, use staged diff

如果文件已暂存，使用暂存区的diff

git diff --staged
git diff --staged

If nothing staged, use working tree diff

如果没有文件暂存，使用工作区的diff

git diff
git diff

Also check status

同时检查状态

git status --porcelain
undefined
git status --porcelain
undefined

2. Stage Files (if needed)

2. 暂存文件（如有需要）

If nothing is staged or you want to group changes differently:
bash
undefined
如果没有文件暂存，或者你想以不同方式分组变更：
bash
undefined

Stage specific files

暂存特定文件

git add path/to/file1 path/to/file2
git add path/to/file1 path/to/file2

Stage by pattern

按模式暂存

git add .test. git add src/components/*
git add .test. git add src/components/*

Interactive staging

交互式暂存

git add -p

**Never commit secrets** (.env, credentials.json, private keys).
git add -p

**绝对不要提交敏感信息**（.env、credentials.json、私钥）。

3. Generate Commit Message

3. 生成提交消息

Analyze the diff to determine:
  • Type: What kind of change is this?
  • Scope: What area/module is affected?
  • Description: One-line summary of what changed (present tense, imperative mood, <72 chars)
分析diff以确定：
  • 类型：这是哪种类型的变更？
  • 范围：哪个区域/模块受到影响？
  • 描述：变更的单行摘要（现在时、祈使语气，不超过72个字符）

4. Execute Commit

4. 执行提交

bash
undefined
bash
undefined

Single line

单行提交

git commit -m "<type>[scope]: <description>"
git commit -m "<type>[范围]: <描述>"

Multi-line with body/footer

多行提交（包含正文/页脚）

git commit -m "$(cat <<'EOF' <type>[scope]: <description>
<optional body> <optional footer> EOF )" ```
git commit -m "$(cat <<'EOF' <type>[范围]: <描述>
<可选正文>
<可选页脚> EOF )"
undefined

Best Practices

最佳实践

  • One logical change per commit
  • Present tense: "add" not "added"
  • Imperative mood: "fix bug" not "fixes bug"
  • Reference issues: 
    Closes #123
    , 
    Refs #456
  • Keep description under 72 characters
  • 每次提交一个逻辑变更
  • 使用现在时：用"add"而非"added"
  • 使用祈使语气：用"fix bug"而非"fixes bug"
  • 关联议题：
    Closes #123
    、
    Refs #456
  • 描述保持在72个字符以内

Git Safety Protocol

Git安全协议

  • NEVER update git config
  • NEVER run destructive commands (--force, hard reset) without explicit request
  • NEVER skip hooks (--no-verify) unless user asks
  • NEVER force push to main/master
  • If commit fails due to hooks, fix and create NEW commit (don't amend)
  • 绝对不要修改git配置
  • 绝对不要在未得到明确请求的情况下运行破坏性命令（--force、硬重置）
  • 除非用户要求，否则绝对不要跳过钩子（--no-verify）
  • 绝对不要强制推送到main/master分支
  • 如果提交因钩子失败，修复后创建新的提交（不要修改现有提交）