git-commit-message-follow-project-convention

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Commit Message — Follow Project Convention

Git提交消息 — 遵循项目规范

Before writing a commit message, analyze the project's recent commit history to learn its conventions. The project's actual conventions always take precedence over any general-purpose commit message guidelines.

在撰写提交消息前，请分析项目近期的提交历史，以了解其规范。项目的实际规范始终优先于任何通用的提交消息指南。

Before You Start (Important!)

开始前须知（重要！）

If a
git-commit
skill is also available, refer to it for general commit workflow guidance (staging, safety checks, etc.) — but always override its message formatting rules with the conventions identified below. For example, if this project does not use conventional commits, you should consider not using it even if the
```
git-commit
```
skill recommends it.
If the project provides it's own commit message guidelines in documentation or in project specific instructions, prioritize those over the conventions you identify from the commit history. The project's official guidelines take precedence over both the commit history and general best practices.

如果同时存在
git-commit
技能文档，可参考它获取通用的提交流程指导（暂存、安全检查等）——但请始终用下文确定的项目规范替代其中的消息格式规则。例如，如果本项目不使用约定式提交，即便
```
git-commit
```
技能文档推荐，也不应采用该方式。
如果项目在文档或特定说明中提供了专属的提交消息指南，请优先遵循这些指南，而非从提交历史中总结的规范。项目的官方指南优先级高于提交历史和通用最佳实践。

Step 1: Retrieve Recent Commits

步骤1：获取近期提交记录

Use a specialized tool if available. Otherwise, run:

bash

git --no-pager log --oneline -30

如果有专用工具，请使用专用工具。否则，运行以下命令：

bash

git --no-pager log --oneline -30

Step 2: Identify Conventions

步骤2：识别项目规范

Examine the retrieved commit messages and determine:

检查获取到的提交消息，确定以下内容：

1. Commit Message Format

1. 提交消息格式

Conventional Commits: Do messages follow the

type(scope): description

pattern (e.g.,

feat: add login page

fix(auth): resolve token expiry

Free-form: Are messages plain sentences without a structured prefix?
Other format: Is there a different structured pattern (e.g., ticket IDs like
```
[PROJ-123] Fix bug
```
, tagged formats like
```
[Feature] Add search
```
)?

约定式提交：消息是否遵循

type(scope): description

格式（例如：

feat: add login page

、

fix(auth): resolve token expiry

）？

自由格式：消息是否为无结构化前缀的普通句子？
其他格式：是否存在其他结构化模式（例如：包含工单ID的
```
[PROJ-123] Fix bug
```
、带标签的
```
[Feature] Add search
```
）？

2. Capitalization

2. 大小写规则

Is the first word of the description lowercase (
```
fix: add validation
```
) or uppercase (
```
fix: Add validation
```
)?
If free-form, do messages start with a capital letter or not?
Are there any other capitalization patterns (e.g.,
```
GitHub
```
or
```
github
```
)?

描述部分的首单词是小写（如
```
fix: add validation
```
）还是大写（如
```
fix: Add validation
```
）？
如果是自由格式，消息是否以大写字母开头？
是否存在其他大小写模式（例如：
```
GitHub
```
或
```
github
```
）？

3. Other Formatting

3. 其他格式规范

Scope usage: If conventional commits are used, are scopes common or rare? What are the typical scopes? (Tip: run
```
git log -3000 --format='%s' | sed -nE 's/^(([a-z]+)?(\([^)]+\))?):.*/\1/p' | grep . | sort | uniq -c | sort -rn | head -50
```
to see the most common types and scopes.)
Ticket/issue references: Are issue numbers or ticket IDs included? Where (prefix, suffix, footer)?
Tense and mood: Are messages in imperative mood (
```
add feature
```
) or past tense (
```
added feature
```
)?
Usage of code fences: "update README.md" or "update
```
README.md
```
", "fix bug in
```
process_data()
```
"?
Message length: Are descriptions typically terse or verbose?
Punctuation: Do messages end with a period or not?

Scope使用：如果使用约定式提交，Scope是常用还是少见？典型的Scope有哪些？（提示：运行
```
git log -3000 --format='%s' | sed -nE 's/^(([a-z]+)?(\([^)]+\))?):.*/\1/p' | grep . | sort | uniq -c | sort -rn | head -50
```
查看最常见的类型和Scope。）
工单/问题引用：是否包含问题编号或工单ID？位置在哪里（前缀、后缀、页脚）？
时态和语气：消息使用祈使语气（如
```
add feature
```
）还是过去时态（如
```
added feature
```
）？
代码围栏使用：是写"update README.md"还是"update
```
README.md
```
"，"fix bug in
```
process_data()
```
"？
消息长度：描述通常是简洁的还是冗长的？
标点符号：消息末尾是否带句号？

Step 3: Write the Commit Message

步骤3：撰写提交消息

Apply the observed conventions to the new commit message. Match the project's style exactly.

将观察到的规范应用到新的提交消息中，完全匹配项目的风格。