跳转到内容
Nick Blogs

git commit 规范

1. 提交内容的原则：原子化 (Atomic Commits)

Section titled “1. 提交内容的原则：原子化 (Atomic Commits)”

原子化提交 是指每次提交只做一件事，且这件事是完整、自包含的。

  • 只做一件事： 如果你修复了一个 Bug，同时又重构了另一个函数，请将其拆分为两次独立的提交。

    好处： 如果重构导致了新问题，你可以安全地只回滚重构的提交，而不影响 Bug 修复。

  • 保持可构建性： 绝不要提交未写完或无法编译的代码。确保每个 commit 后的代码库都是可以通过编译和测试的。

  • 小步快跑： 频繁提交小的改动，而不是积攒了一周的修改后才提交一个巨大的“大礼包”提交。

2. 提交信息的规范：约定式提交 (Conventional Commits)

Section titled “2. 提交信息的规范：约定式提交 (Conventional Commits)”

目前业界最推崇的是 Conventional Commits（约定式提交） 规范。其基础格式如下：

type(scope): description

2.1. 常见的 Type（类型）

Section titled “2.1. 常见的 Type（类型）”
类型含义
feat引入新功能 (Feature)
fix修复 Bug (Bug Fix)
docs仅修改文档（如 README, API 接口文档, 代码注释）
style仅格式化、缺失分号等不影响代码运行逻辑的修改
refactor代码重构（既不是修复 Bug 也不是加功能）
perf旨在提高性能的代码修改
test增加或修改测试用例
chore构建过程或辅助开发工具的变动（如修改 .gitignore, 配置依赖库）

2.2. 示例

Section titled “2.2. 示例”
  • feat(auth): 增加微信登录功能
  • fix(order): 修复订单金额计算精度问题

3. 编写优秀的 Message 体例

Section titled “3. 编写优秀的 Message 体例”

一个专业的提交信息通常遵循 “50/72 规则”：

  1. 标题（第一行）： 控制在 50 个字符 以内。首字母大写，末尾不要加句号。
  2. 空行： 标题和正文之间必须留出空行。
  3. 正文（可选）： 每行不超过 72 个字符。解释 为什么 做这个改动，以及 如何 解决的问题（而不是机械复述代码改了什么）。

4. 提交前的检查清单

Section titled “4. 提交前的检查清单”

在输入 git commit 之前，自我审查以下三个问题：

  • 我是否在本地运行并通过了测试？ 永远不要把未经测试通过的代码推入版本库。
  • 是否有无关的代码修改混入？ 使用 git diff --cached 仔细检查暂存区，剔除临时性的打印语句（如 console.log）或开发临时注释。
  • 我的提交信息足够清晰吗？ 半年后重新看这条 Commit 信息，我还能清晰回忆起当时为什么要这么做吗？

5. 进阶常用命令

Section titled “5. 进阶常用命令”

5.1. 合并到上一次提交

Section titled “5.1. 合并到上一次提交”

如果你刚刚完成提交，却发现漏改了一个单词，可以使用 --amend 合并修改，而不需要重新生成一个新的 Commit：

Terminal window
# 将漏改的文件加入暂存区
git add .
# 合并到上一次提交，保持原有的提交信息不变
git commit --amend --no-edit

5.2. 交互式分块暂存

Section titled “5.2. 交互式分块暂存”

如果在一个文件里改了两个不相关的模块功能，可以使用交互式暂存进行精细化拆分：

Terminal window
git add -p <file_name>

[!info] 该命令会交互式地展现每一块修改，允许你逐块选择 y (暂存本块) 或 n (不暂存本块)，从而优雅地将一个文件内的多处修改拆分到不同提交中。