commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commit

提交

Write a commit message from the staged changes only, then commit.

仅根据 已暂存（staged） 的更改编写提交信息，然后提交。

Steps

步骤

Inspect state — run these together:
- ```
git status --short
```
- ```
git diff --staged --stat
```
- ```
git diff --staged
```
  (if huge, read the stat plus diffs of the most important files)
- ```
git log --format='%s' -n 20
```
  (match the repo's existing style)
If nothing is staged, stop and tell the user. Do not
```
git add -A
```
unless they asked.
Understand why the change was made, not just what lines moved. Group the diff into one logical change; if the staged diff clearly contains several unrelated changes, say so and suggest splitting.
Draft the message and show it to the user in a fenced code block. Stop there — do not commit yet. Ask them to approve, or reply with edits.
- Never run
```
git commit
```
  in the same turn as the draft, not even with
```
--dry-run
```
  as a substitute for asking.
- If they request changes, redraft and ask again.
Only after the user approves, commit with
```
git commit -m "..."
```
(repeated
```
-m
```
for body/footer).
Report the resulting
```
git log -1 --stat
```
briefly.

检查状态 —— 一起运行以下命令：
- ```
git status --short
```
- ```
git diff --staged --stat
```
- ```
git diff --staged
```
  （如果内容很大，阅读 stat 以及最重要文件的 diff）
- ```
git log --format='%s' -n 20
```
  （匹配仓库现有的风格）
如果没有已暂存的内容，停下来并告知用户。除非用户要求，否则不要执行
```
git add -A
```
。
理解更改的原因，而不只是哪些行发生了变动。将 diff 归为一个逻辑变更；如果暂存的 diff 明显包含多个不相关的更改，请说明并建议拆分。
起草提交信息，并以围栏代码块的形式展示给用户。到此为止 —— 先不要提交。 请用户批准，或回复修改意见。
- 绝不要在起草信息的同一轮对话中运行
```
git commit
```
  ，即使是
```
--dry-run
```
  也不能替代用户的确认。
- 如果用户要求修改，请重新起草并再次确认。
只有在用户批准后，才使用
```
git commit -m "..."
```
提交（正文/页脚可重复使用
```
-m
```
）。
简要报告执行后的
```
git log -1 --stat
```
结果。

Format

格式

<type>(<optional scope>): <subject>

- <optional body, max 3 bullets, one line each — why, not what>

<optional footer — BREAKING CHANGE: ..., Refs #123>

Types:

feat

fix

refactor

perf

docs

style

test

build

ci

chore

revert

Subject rules

Imperative mood: "add", "fix", "remove" — not "added"/"adds".
Lowercase start, no trailing period, ≤ 50 chars (hard cap 72).

Say the effect, not the file list. Bad:

update CommentSelectRow.vue

. Good:

filter comments by asset when attaching to a DF

Scope = the affected area (module, feature, package), only if it adds clarity.

Body — keep it short; most commits don't need one

Default to no body. Add one only when the subject can't carry the why.
Point form only:
```
- 
```
bullets, never prose paragraphs.
Max 3 bullets. One line each (≤ 72 cols) — if a bullet wraps, cut it down.
Say the reason or the catch, not a summary of the diff. The diff is already in the commit.
Don't list files, don't enumerate everything the change touches.

Footer

```
BREAKING CHANGE: <description>
```
for incompatible changes (or
```
!
```
after the type/scope).
Issue refs:
```
Refs #123
```
,
```
Fixes #123
```
.

<type>(<optional scope>): <subject>

- <optional body, max 3 bullets, one line each — why, not what>

<optional footer — BREAKING CHANGE: ..., Refs #123>

类型：

feat

、

fix

、

refactor

、

perf

、

docs

、

style

、

test

、

build

、

ci

、

chore

、

revert

主题规则

使用祈使语气："add"、"fix"、"remove" —— 不要用 "added"/"adds"。
小写字母开头，结尾不加句号，≤ 50 个字符（硬上限 72）。
说明影响，而不是文件列表。错误示例：
```
update CommentSelectRow.vue
```
。正确示例：
```
filter comments by asset when attaching to a DF
```
。
范围（scope）= 受影响的区域（模块、功能、包），仅在能增加清晰度时使用。

正文 —— 保持简短；大多数提交不需要正文

默认不写正文。只有主题无法承载原因时才添加。
仅使用要点形式：
```
- 
```
项目符号，不要用散文段落。
最多 3 条要点。每行一条（≤ 72 列）——如果一条要点换行，就把它缩短。
说明原因或注意事项，而不是 diff 的摘要。diff 已经包含在提交中了。
不要列出文件，不要枚举更改涉及的所有内容。

页脚

不兼容变更使用
```
BREAKING CHANGE: <描述>
```
（或在类型/范围后加
```
!
```
）。
问题引用：
```
Refs #123
```
、
```
Fixes #123
```
。

Rules

规则

Always get explicit approval on the drafted message before committing. No exceptions, even for a one-line trivial change.
Never invent a ticket number, cause, or intent not visible in the diff or conversation.
Never mention tooling that produced the change unless the user asks.
Don't add co-author or generated-by trailers unless the repo/user requires it.
If the repo's history clearly uses a different convention, follow the repo.

提交前必须获得用户对草稿信息的明确批准。 没有例外，即使是一行的小改动。
绝不虚构在 diff 或对话中看不到的工单号、原因或意图。
除非用户要求，否则不提产生该更改的工具。
除非仓库/用户要求，否则不添加 co-author 或 generated-by 尾部信息。
如果仓库历史明显使用不同的约定，请遵循该仓库的约定。

Examples

示例

fix: prevent duplicate asset rows in comment picker

- Dedupe ran before the asset filter, so one asset per linked deal.
- Now keyed on reference id.

Fixes #482

refactor(queue): move retry config out of the job classes

feat(auth)!: require MFA for admin logins

BREAKING CHANGE: existing admin sessions are invalidated on deploy.

fix: prevent duplicate asset rows in comment picker

- Dedupe ran before the asset filter, so one asset per linked deal.
- Now keyed on reference id.

Fixes #482

refactor(queue): move retry config out of the job classes

feat(auth)!: require MFA for admin logins

BREAKING CHANGE: existing admin sessions are invalidated on deploy.