「技术博客」关于Git Commit，你需要知道

前言：如果你在Github上关注了许多的项目或者用户，你就会发现，他们的每一个commit好像都遵循着某种特别的格式，即使对于不同的用户而言。

如果你也是这样一个有着惊人观察力的人类，那么，恭喜你，这篇博客就是为了解决你的需求而写的。

关于Commit Message的注意点

首先，对于大多数项目来说，他们的提交信息都遵循 [Conventional Commits ](Conventional Commits)规范，这是如今最流行的信息提交模版。 以下，是其基本格式：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

type

type是我们的提交所属于的类型：

类型	用途	示例
feat	新功能（触发 minor 版本升级）	feat: 添加邮件通知
fix	Bug 修复（触发 patch 版本升级）	fix: 修复空指针崩溃
docs	仅文档变更	docs: 更新 API 文档
style	代码格式（空格、分号等）	style: 删除多余空行
refactor	重构代码（非 Bug 也非新功能）	refactor: 提取公共函数
test	添加/修改测试	test: 添加登录单元测试
chore	构建、工具配置等杂务	chore: 升级依赖包
perf	性能优化	perf: 提升查询速度 50%
同时，type也是我们必须要在信息中标明的。

scope

所谓scope，其实是我们更改的文件的范围。

例如，你修改了一个web接口，那么，你可能填写的就是这个接口在接口文档中所处的文件夹。

可以是文件名、模版名或者功能区域，我们需要使用简洁的命名。

# 正确示例
feat(auth): 添加 JWT 验证
fix(api/user): 修复用户列表分页
docs(readme): 添加安装说明

# 错误示例
feat(Auth): 添加 JWT 验证  ← 不应大写
feat(用户认证): 添加 JWT 验证  ← 应使用英文

description

description是用一句话甚至一个动名词总结出的，我们所修改的代码的作用或功能。

如果你是英语提交的话，需要使用现在时态，以小写文字开头，末尾不要加句号。

# 优秀示例
feat: 支持微信支付

# 较差示例
feat: 添加了微信支付的功能。  ← 过长、过去式、有句号

body

（注意！如果要使用body，请务必和标题隔一行，以确保git自动识别标题）

如果你还有其他话需要补充或者功能过于复杂的情况下，你可能会用到body，你提交信息的主体内容。

• 每行最多72个字符。（来自Unix终端的传统）
• 解释“为什么”和“如何“，而不只是”做了什么“。
• 使用现在时态。
• 可以包含多个段落。

fix: 修复订单并发创建问题

之前的实现使用全局计数器，在高并发下出现重复订单号。
现在改用数据库序列 + 分布式锁，保证唯一性。

修改包括：
- 新增 OrderSequence 表
- 添加 Redis 分布式锁
- 移除旧的计数器逻辑

测试：模拟 1000 并发请求，无重复订单

footer

footer，即脚注，标明了我们的补充内容。

通常，在以下情况使用：

1. 关联了某个Issue。
2. 进行了破坏性更新。
3. 添加审核信息。

Closes #123
Fixes #456
Related to #789

feat(auth): 移除 Session 支持

用户认证现在只支持 JWT 令牌。

BREAKING CHANGE: 原有基于 Session 的代码需要迁移到 JWT。
配置项 `session_secret` 已被移除，请改用 `jwt_secret`。

Reviewed-by: Crist <cr1st4ever@outlook.com>
Refs: #feature/auth-redesign

为什么要这样设计

1. 自动化工具支持。
2. 提升可读性。
3. 使得代码审查更高效。
4. 更好的 git blame 理解。
5. 自动生产发布说明。

---