git

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git

Commits

提交

Grouping

分组

Group changes into cohesive commits by unit of work: one commit per logical change that could be deployed, reverted, or cherry-picked independently.
When a diff spans multiple concerns (feature + refactor, fix + test, rename + behavior change), split into separate commits. Stage files selectively with
```
git add <paths>
```
.
Ask yourself: "if this commit were reverted, would exactly one coherent thing disappear?" If not, split it.

按工作单元将改动分组为内聚的提交：每个可独立部署、回滚或cherry-pick的逻辑改动对应一个提交。
当一个diff涉及多个关注点（功能+重构、修复+测试、重命名+行为变更）时，拆分为独立提交。使用
```
git add <paths>
```
选择性暂存文件。
自问："如果回滚这个提交，是不是刚好只会移除一个完整的逻辑改动？"如果不是，就拆分提交。

Conventional Commit Format

约定式提交格式

<type>[scope]: <description>

[body]

[footer]

Types:

feat

fix

docs

style

refactor

perf

test

build

ci

chore

revert

Derive type and scope from the diff, not from the user's words.
Description: imperative mood, present tense, under 72 chars. "add", not "added" or "adds".
Body: explain why, not what. The diff already shows the what.
Breaking changes: add
```
!
```
after type/scope and a
```
BREAKING CHANGE:
```
footer.
Reference issues in the footer:
```
Closes #123
```
,
```
Refs #456
```
.

<type>[scope]: <description>

[body]

[footer]

类型：

feat

fix

docs

style

refactor

perf

test

build

ci

chore

revert

。

从diff推导类型和作用域，不要依据用户的口头描述。
描述：使用祈使语气、现在时态，长度不超过72个字符。用"add"，不要用"added"或"adds"。
正文：解释为什么做改动，而不是做了什么改动。diff已经展示了改动内容。
破坏性变更：在类型/作用域后添加
```
!
```
，并在页脚添加
```
BREAKING CHANGE:
```
说明。
在页脚关联issue：
```
Closes #123
```
,
```
Refs #456
```
。

Authoring

提交人信息

Read author name and email from
```
git config user.name
```
and
```
git config user.email
```
before every commit. Use those values exclusively - never substitute another identity.
Commits are the user's work. Omit
```
Co-Authored-By
```
trailers for LLMs.

Honor the user's signing config (

commit.gpgsign

user.signingkey

). Never pass

--no-gpg-sign

-c commit.gpgsign=false

每次提交前从
```
git config user.name
```
和
```
git config user.email
```
读取提交人姓名和邮箱。仅使用这些值，绝对不要替换为其他身份。
提交属于用户的工作成果。不要为LLM添加
```
Co-Authored-By
```
标识。
遵守用户的签名配置（
```
commit.gpgsign
```
、
```
user.signingkey
```
）。绝对不要使用
```
--no-gpg-sign
```
或
```
-c commit.gpgsign=false
```
参数。

Safety

安全注意事项

Read
```
git diff --staged
```
(or
```
git diff
```
when nothing is staged) and
```
git status --porcelain
```
before committing.
Stage files explicitly by path. Avoid
```
git add -A
```
or
```
git add .
```
to prevent leaking secrets or binaries.
Leave hooks enabled. When a hook fails, fix the issue and create a new commit - never amend the failed one.
Reserve destructive commands (
```
--force
```
,
```
reset --hard
```
,
```
clean -f
```
,
```
branch -D
```
) for explicit user requests.

提交前读取
```
git diff --staged
```
（无暂存内容时读取
```
git diff
```
）和
```
git status --porcelain
```
的输出。
明确按路径暂存文件。避免使用
```
git add -A
```
或
```
git add .
```
，防止泄露密钥或二进制文件。
保持钩子启用状态。如果钩子执行失败，修复问题后创建新提交——绝对不要amend执行失败的提交。
破坏性命令（
```
--force
```
、
```
reset --hard
```
、
```
clean -f
```
、
```
branch -D
```
）仅在用户明确要求时使用。

Pull Requests

拉取请求（PR）

Title

标题

Use conventional commit format:
```
<type>[scope]: <description>
```
.
Keep under 70 characters. Put detail in the body.

使用约定式提交格式：
```
<type>[scope]: <description>
```
。
长度保持在70个字符以内，详细内容放在正文中。

Body

正文

undefined

undefined

Summary

<1-3 bullet points explaining why this change exists>

<1-3条要点说明该变更的存在原因>

Changes

<按逻辑分组的改动列表>

Test plan

<How to verify correctness> ```

Write the summary from all commits on the branch, not just the latest one.
Link related issues:
```
Closes #N
```
,
```
Refs #N
```
.

<如何验证变更正确性>


- 基于分支上的所有提交撰写摘要，不要仅参考最新提交。
- 关联相关issue：`Closes #N`, `Refs #N`。

gh CLI

Use
```
gh pr create --title "..." --body "..."
```
with a heredoc for multi-line bodies.
Use
```
gh pr view
```
,
```
gh pr checks
```
,
```
gh pr merge
```
for PR lifecycle management.
Use
```
gh issue list
```
,
```
gh issue view
```
for issue context before writing PR descriptions.
Push with
```
git push -u origin HEAD
```
before creating a PR when the remote branch is missing.

使用
```
gh pr create --title "..." --body "..."
```
命令，多行正文使用heredoc传入。
使用
```
gh pr view
```
、
```
gh pr checks
```
、
```
gh pr merge
```
管理PR生命周期。
编写PR描述前，使用
```
gh issue list
```
、
```
gh issue view
```
获取issue上下文。
当远程分支不存在时，创建PR前先执行
```
git push -u origin HEAD
```
推送代码。