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

基于conventional commits，应该如何对仅UI更改进行分类？例如，假设将注销按钮从屏幕底部移至顶部，在文本旁边添加了一个图标，并且有一个新的动画。除此之外，从功能的角度来看，什么都没有改变。

我的困惑来自这种（可能是错误的）推理。您不能使用以下任何一项，因为：

壮举：这不是新功能
修复：没有要修复的错误
性能：性能没有受到影响
重构：在Angular definition重构“既无法修复错误也未添加功能的代码更改”之后，但在不使用重构Wikipedia definition的情况下，可能就是这种情况。重构现有计算机代码的过程（更改因数）而无需更改其外部行为”
样式：不会影响代码含义的更改（空格，格式，缺少分号等）。很明显，事实并非如此

功能不必很大。尽管代码更改很小，但注销链接的重定位是面向用户的，因此是一项功能。可以使用“ feat”前缀进行提交。

壮举：将注销链接移至页面顶部，解决＃1234

另一方面，如果从未希望注销链接位于底部，则将其移至顶部更正了该问题，则在消息前使用“ fix：”。

修复：将注销链接移至页面顶部。修复＃1234

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

常规提交规范的任务声明如下：

添加人和机器可读含义以提交消息的规范

然后其他工具可以使用该规范来确定变更集是否需要发布。

但是，这些都不是要知道您要发布的内容还是打算完全发布。

例如，其中某些工具不会发布仅包含docs或style类型提交的变更集。毕竟，私有功能文档的更改或将制表符转换为空格不会真正影响最终用户。因此，下次您进行“有意义的”提交时，变更集将在发行版中发布。

然而，与几乎所有内容一样，上下文是关键：

在NPM库中，自述文件始终是软件包的一部分。如果存在事实错误或遗漏某些内容，您可能希望尽快进行更改。因此，docs类型的提交在这里可能不合适。也许这更像是fix？
在Git管理的博客中，仅空格更改实际上可以提高内容的可读性。在这里feat类型的提交会更合适吗？

您为什么要进行此更改？

正如我在上面试图说明的那样，上下文很重要。不要以看到的面子为例。