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

Question

根据传统的提交，单纯的 UI 更改应该如何分类？例如，假设注销按钮从屏幕底部移动到顶部，文本旁边添加了一个图标，并且有一个新的动画。除此之外，从功能角度来看没有任何变化。

\n

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

\n

\n
• 壮举：这不是一个新功能
\n
• 修复：没有任何需要修复的错误
\n
• perf：未涉及性能
\n
• 重构：这可能是遵循Angular重构定义“既不修复错误也不添加功能的代码更改”的情况，但不使用重构的维基百科定义“代码重构是重组现有计算机代码的过程\xe2\” x80\x94更改分解\xe2\x80\x94而不改变其外部行为”
\n
• 样式：不影响代码含义的更改（空格、格式、缺少分号等）。不言而喻，事实并非如此
\n

\n

Answer 1

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

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

另一方面，如果注销链接不应该位于底部，而将其移动到顶部可以纠正该问题，则可以在消息之前使用“fix:”。

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

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