git - 如何根据常规提交规范对 UI 更改进行分类？

Question

基于 conventional commits单纯的 UI 更改应该如何分类？例如，假设一个注销按钮从屏幕底部移到顶部，文本旁边添加了一个图标，并且有一个新动画。除此之外，从功能的角度来看，没有任何变化。
我的困惑来自这个(可能是错误的)推理。您不能使用以下任何一项，因为:

壮举:这不是新功能

修复:没有任何错误需要修复

perf:未触及性能

重构:这可能是在 Angular definition 之后的情况重构“既不修复错误也不添加功能的代码更改”，但不使用 Wikipedia definition重构“代码重构是重构现有计算机代码的过程——改变分解——而不改变其外部行为”

样式:不影响代码含义的更改(空格、格式、缺少分号等)。不言而喻，事实并非如此

Answer 1

一个特征不需要很大。尽管代码更改非常小，但注销链接的重定位是面向用户的，因此是一项功能。为您的提交使用“feat”前缀是可以接受的。

feat: moved logout link to top of page, resolves #1234

另一方面，如果注销链接从不应该在底部，并将其移到顶部更正了这一点，那么在您的消息之前使用“修复:”。

fix: moved logout link to top of page. Fixes #1234

您链接到的文章提到了很多关于语义版本控制的内容，并且似乎更适合 API 而不是整个应用程序，因此不存在对应用程序更改的精确转换，但您可以进行一些关联。