semantic-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Semantic Commit

语义化提交

Describe the actual change precisely. Never invent scope, motivation, issue IDs, tests, or breaking changes.

请精准描述实际变更内容。切勿编造范围、动机、问题ID、测试内容或破坏性变更。

Workflow

工作流程

Read repository instructions and inspect
```
git status
```
, the staged diff, the unstaged diff, and recent commit subjects.
If a commit was requested, verify which files are intended. Do not stage unrelated changes or modifications made by someone else.
Derive the primary user-visible or engineering intent from the staged diff, not from filenames alone.
Select the narrowest valid type and an optional scope consistent with repository history.
Write an imperative, concise subject with no trailing period. Keep it independently understandable.
Add a body only when the reason, behavior, migration, risk, or non-obvious trade-off needs explanation.
Add footers for breaking changes, issue references, co-authors, or repository-required metadata only when supported by evidence.
Validate that the message describes all staged changes. Split unrelated changes into separate commits when explicitly authorized.

阅读仓库说明并检查
```
git status
```
、暂存差异、未暂存差异以及近期提交主题。
如果用户要求执行提交，请确认目标文件。不要暂存无关变更或他人做出的修改。
从暂存差异中提炼主要的用户可见意图或工程意图，而非仅依赖文件名。
选择最精准的有效类型，并可根据仓库历史添加可选范围。
编写祈使语气、简洁的主题，末尾不要加句号。确保主题可独立理解。
仅当需要解释变更原因、行为、迁移方案、风险或非显而易见的权衡时，才添加正文内容。
仅当有证据支持时，才为破坏性变更、问题引用、共同作者或仓库要求的元数据添加页脚。
验证提交信息是否涵盖所有暂存变更。仅在明确获得授权时，将无关拆分为独立提交。

Conventional Commit Format

Conventional Commits 格式

text

<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

Common types:

```
feat
```
: new user-facing capability.
```
fix
```
: defect correction.
```
refactor
```
: internal change without intended behavior change.
```
perf
```
: measurable performance improvement.
```
test
```
: test-only change.
```
docs
```
: documentation-only change.
```
build
```
: build system or dependency change.
```
ci
```
: CI/CD configuration or workflow change.
```
chore
```
: maintenance that fits no more specific type.
```
revert
```
: reverts an earlier commit.

Use

and a

BREAKING CHANGE:

footer only for an incompatible public behavior, API, schema, protocol, configuration, or operational contract.

text

<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

常见类型：

```
feat
```
: 新增面向用户的功能。
```
fix
```
: 修复缺陷。
```
refactor
```
: 内部变更，不改变预期行为。
```
perf
```
: 可衡量的性能提升。
```
test
```
: 仅涉及测试的变更。
```
docs
```
: 仅涉及文档的变更。
```
build
```
: 构建系统或依赖项变更。
```
ci
```
: CI/CD配置或工作流程变更。
```
chore
```
: 不属于更具体类型的维护工作。
```
revert
```
: 回滚之前的提交。

仅当存在不兼容的公开行为、API、 schema、协议、配置或操作约定时，才使用

和

BREAKING CHANGE:

页脚。

Guardrails

约束规则

Do not use
```
feat
```
for every code addition or
```
fix
```
for speculative cleanup.
Do not bundle generated files, formatting, or dependency changes unless they belong to the same atomic change.
Never bypass hooks, amend, force-push, or rewrite history without explicit instruction.
Never expose secrets from diffs in the commit message.
Run repository-required checks before committing when feasible, and report checks that were not run.

不要对所有代码新增都使用
```
feat
```
类型，也不要对推测性清理使用
```
fix
```
类型。
不要将生成文件、格式调整或依赖项变更捆绑在一起，除非它们属于同一原子变更。
除非有明确指令，否则不要绕过钩子、修改提交、强制推送或重写历史。
切勿在提交信息中暴露差异中的机密内容。
可行的话，在提交前运行仓库要求的检查，并报告未执行的检查项。

Output

输出

When only a message is requested, return the proposed message in a text block plus a one-line rationale if needed. When a commit is explicitly requested, show the selected files, checks run, resulting commit hash and subject, and confirm that no push occurred unless requested.

当仅请求提交信息时，返回文本块形式的建议信息，必要时附加一行说明理由。当明确请求执行提交时，展示所选文件、已运行的检查、生成的提交哈希和主题，并确认未执行推送操作（除非用户要求）。