新功能、更新、设计是否使用功能：在语义提交消息约定中？答案

【问题标题】：Do new features, updates, design use feat: in semantic commit message convention?新功能、更新、设计是否使用功能：在语义提交消息约定中？
【发布时间】：2021-07-17 09:01:55
【问题描述】：

我决定在我的新玩具项目中使用语义提交消息。
我看到了各种类型的语义提交消息。

feat: (new feature for the user, not a new feature for build script)
fix: (bug fix for the user, not a fix to a build script)
docs: (changes to the documentation)
style: (formatting, missing semi colons, etc; no production code change)
refactor: (refactoring production code, eg. renaming a variable)
test: (adding missing tests, refactoring tests; no production code change)
chore: (updating grunt tasks etc; no production code change)

面向前端工程师
设计、更新和新功能，它们都使用语义feat:?
没有像“设计：”或“更新：”这样的语义吗？？

【问题讨论】：

你能举一个不属于其他类别的“设计”或“更新”的例子吗？

标签： git commit

【解决方案1】：

让我们看看the motivation for semantic commit messages。

您再也不会想在同一个提交中包含错误修复和功能。我的 git 日志现在是一个易于浏览的更改日志。

提交只做一件事。
git log 很容易浏览。

如果您认为某些新标签会鼓励您的特定项目的小提交和可读日志，请添加它们。但首先，请考虑是否需要。

update 似乎很模棱两可。不都是更新吗？你在更新什么，为什么？如果要修复错误，那就是fix。如果要添加功能，那就是feat。如果它正在更新依赖项，那就是chore。

design...如果这是对图像、字体、CSS 等的样式更改...可能是style。或者它可能足够独特和常见，足以保证一个新的标签。也许assets 用于仅涉及资产的提交？

【讨论】：

@seongkukhan 如果您要更改 HTML 和 CSS 的代码样式，它就是样式。如果您要更改设计风格，例如将方形图标更改为圆形图标，这是一项功能吗？是否存在不是功能的前端资产更改？具体的例子会有所帮助！重要的是标签对你的项目有意义。它们使您的提交保持专注，并且日志易于浏览。如果现有标签对前端工作没有意义，请使用有意义的标签。我不是前端的人，说不上用什么标签，但是design和update看起来很宽泛，很模糊。
感谢您的回复 :) 您帮了很多忙。我认为“风格”是不错的选择之一。