我决定在我的新玩具项目中使用语义提交消息。
我看到了各种类型的语义提交消息。
| 类型 | 描述 |
|---|---|
| 壮举 | 用户的新功能，而不是构建脚本的新功能 |
| 修复 | 为用户修复错误，而不是修复构建脚本 |
| 文档 | 文档更改 |
| 风格 | 格式错误、缺少分号等；没有生产代码更改 |
| 重构 | 重构生产代码，例如。重命名变量 |
| 测试 | 添加缺失的测试、重构测试；没有生产代码更改 |
| 家务 | 更新繁重任务等；没有生产代码更改 |
对于前端工程师
设计、更新和新功能，所有这些都使用语义
feat:design:update:style前端更改的一些示例：
| 你改变了什么 | 提交类型 |
|---|---|
| 您为页面页脚添加了 html/css | 壮举 |
| 你修复了 IE6 中的 CSS 问题（笑） | 修复 |
| 您在页脚添加了一个链接 | 壮举 |
| 您检查了 css 并修复了缩进问题和缺少分号 | 风格 |
| 您优化了 CSS 动画以获得更高的帧速率 | 性能 |
| 您添加了打印样式 | 壮举 |
| 您移植了现有的 css 并选择从现在开始使用 SASS | 重构 |
让我们看一下语义提交消息的动机。
您将永远不会再试图在同一提交中包含错误修复和功能。我的 git 日志现在是一个易于浏览的变更日志。
git log如果您认为某些新标签会鼓励您的特定项目进行小型提交和可读日志，请添加它们。但首先，请考虑是否需要。
updatefixfeatchoredesignstyleassets