Git提交规范

目录

• commit 规范
  • 提交类型
  • 修改域
  • 提交说明
  • 提交角标
• 参考资料

---

规范的提交规范可以帮助团队成员快速了解项目，减少沟通的时间代价

1. 避免把多个事项的代码一起提交，应该把每个功能都提交一个 commit，这样便于团队成员 review

commit 规范

相对详细的规范的格式为：

<提交类型>(<修改域>): <标题>

<正文>

<角标>

如果嫌麻烦的话，也可以缩短为一行，即：

<提交类型>(<修改域>): <标题>

例子：

fix(middleware): ensure Range headers adhere more closely to RFC 2616

Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.

Fixes #2310

提交类型

一般来说有如下建议：

• feat (为用户添加的新功能，不包括构建脚本的更新)
• fix (修复用户端的 bug，不包括构建脚本的 Bug 修复)
• docs (对文档的更改)
• style (格式化，缺少分号等；没有生产代码变更)
• refactor（重构生产代码，例如重命名变量）
• test（添加缺失的测试，重构测试；无生产代码变更）
• chore (更新 Grunt 任务等；无生产代码变更)
• perf (优化相关，例如提升性能、体验)
• revision (版本回退)
• merge (合并分支)

修改域

修改域是提交代码的修改范围，一般有如下建议：

• init 初始化
• runner 运行器
• watcher 监视器
• config 配置
• web-server 网络服务器
• proxy 代理
• etc. 等。

提交说明

标题应该简单，不超过 50 个字符，尽量避免使用换行符

正文中详细描述提交

提交角标

当本次提交有特殊说明时，在提交说明后添加角标， 修复了对应 issue 的 bug 时：

Fixes #123

// 修复了多条issue
Fixes #123, #456

参考资料

• Semantic Commit Messages 这篇相对简短
• Git Commit Msg 这篇给出了比较合适的案例
• Conventional Commits 1.0.0 这篇比较详细