你每次的 Commit 应该是什么样的？

博主：茶白
发布时间：2025 年 10 月 27 日
9681 次浏览
关闭评论
1498字数
分类：经验

Loading...

### 你每次的 Commit 应该是什么样的？

一个业内广泛推荐的标准是 **Conventional Commits** (约定式提交)。这种规范非常有助于保持提交历史的清晰性、可读性，并且可以基于这些 `commit` 自动生成版本更新日志 (CHANGELOG)。

#### 1\. 基本格式

一个标准的 Conventional Commit 格式如下：

<类型>(<范围>): <主题>

[可选的正文]

[可选的页脚]

```
* **Header (必需):** 包含类型、可选的范围和主题。
  * **Body (可选):** 详细描述变更，说明*为什么*要这样改，以及它解决了什么问题。
  * **Footer (可选):** 通常用来放不兼容的变更 (Breaking Changes) 或关闭 Issue (例如 `Closes #123`)。

-----

#### 2\. 详解

**A. `<类型>` (type) (必需)**

这说明了你这次提交的**类别**，常用的有：

* `feat`: **新功能** (feature)
  * `fix`: **修复 Bug**
  * `refactor`: **代码重构** (既不是加新功能，也不是改 Bug)
  * `docs`: **文档** (documentation) 变更
  * `style`: **格式** (不影响代码运行的变动，例如空格、分号、格式化)
  * `test`: 增加或修改**测试**
  * `chore`: **杂务** (构建过程、辅助工具、依赖库的变动等)

**B. `<范围>` (scope) (可选)**

用于说明 `commit` 影响的范围，比如是哪个模块。例如：`auth`、`ui`、`product-page`。

**C. `<主题>` (subject) (必需)**

* 对变更的简洁描述，**使用祈使句（动词原形）开头**，比如 "add" 而不是 "added" 或 "adds"。
  * 首字母小写。
  * 结尾不加句号 `.`。

-----

### 如何修改你的例子？

假设你**已经完成**了“将产品详情页的输入框改成富文本编辑器”这个任务。

根据 Conventional Commits 规范，你的 `commit` 信息可以这样写：

**英文示例：**
```

feat(product): implement rich text editor for product details

```
或者
```

feat(product): replace text input with rich text editor on details page

```
**中文示例 (如果你的团队使用中文)：**
```

feat(商品): 为产品详情页实现富文本编辑器

#### 为什么这样更好？

1. **`feat`**：明确表示这是一个“新功能”。
2. **`(product)`**：明确表示影响的是“商品”模块。
3. **`implement rich text editor...`**：用动词开头，清晰地描述了“做了什么”。

当你或你的同事回顾提交历史时，看到这样的信息会一目了然，而不需要点开看代码才知道这个 `commit` 到底干了什么。

最后修改：2025 年 10 月 27 日

© 允许规范转载

如果觉得我的文章对你有用，请随意赞赏

此处评论已关闭

姓名
GPT-4 currently has a cap of 25...
曲阜
有没有兴趣来我们公司工作？可联系微信geezzi
Rorinl
谢谢ヾ(≧∇≦*)ゝ
rorinl
该评论仅登录用户及评论双方可见

你每次的 Commit 应该是什么样的？

茶白 • 2025 年 10 月 27 日

Loading...

### 你每次的 Commit 应该是什么样的？

一个业内广泛推荐的标准是 **Conventional Commits** (约定式提交)。这种规范非常有助于保持提交历史的清晰性、可读性，并且可以基于这些 `commit` 自动生成版本更新日志 (CHANGELOG)。

#### 1\. 基本格式

一个标准的 Conventional Commit 格式如下：

<类型>(<范围>): <主题>

[可选的正文]

[可选的页脚]

```
* **Header (必需):** 包含类型、可选的范围和主题。
  * **Body (可选):** 详细描述变更，说明*为什么*要这样改，以及它解决了什么问题。
  * **Footer (可选):** 通常用来放不兼容的变更 (Breaking Changes) 或关闭 Issue (例如 `Closes #123`)。

-----

#### 2\. 详解

**A. `<类型>` (type) (必需)**

这说明了你这次提交的**类别**，常用的有：

* `feat`: **新功能** (feature)
  * `fix`: **修复 Bug**
  * `refactor`: **代码重构** (既不是加新功能，也不是改 Bug)
  * `docs`: **文档** (documentation) 变更
  * `style`: **格式** (不影响代码运行的变动，例如空格、分号、格式化)
  * `test`: 增加或修改**测试**
  * `chore`: **杂务** (构建过程、辅助工具、依赖库的变动等)

**B. `<范围>` (scope) (可选)**

用于说明 `commit` 影响的范围，比如是哪个模块。例如：`auth`、`ui`、`product-page`。

**C. `<主题>` (subject) (必需)**

* 对变更的简洁描述，**使用祈使句（动词原形）开头**，比如 "add" 而不是 "added" 或 "adds"。
  * 首字母小写。
  * 结尾不加句号 `.`。

-----

### 如何修改你的例子？

假设你**已经完成**了“将产品详情页的输入框改成富文本编辑器”这个任务。

根据 Conventional Commits 规范，你的 `commit` 信息可以这样写：

**英文示例：**
```

feat(product): implement rich text editor for product details

```
或者
```

feat(product): replace text input with rich text editor on details page

```
**中文示例 (如果你的团队使用中文)：**
```

feat(商品): 为产品详情页实现富文本编辑器

#### 为什么这样更好？

1. **`feat`**：明确表示这是一个“新功能”。
2. **`(product)`**：明确表示影响的是“商品”模块。
3. **`implement rich text editor...`**：用动词开头，清晰地描述了“做了什么”。

当你或你的同事回顾提交历史时，看到这样的信息会一目了然，而不需要点开看代码才知道这个 `commit` 到底干了什么。