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

Question

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

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

壮举：这不是一个新功能
修复：没有要修复的错误
perf：性能未触及
重构：这可能是遵循Angular对重构的定义“既不修复错误也不添加功能的代码更改”，但不使用Wikipedia对重构的定义“代码重构是重构现有计算机代码的过程——改变因式分解——不改变其外部行为”
样式：不影响代码含义的更改（空格、格式、缺少分号等）。不言而喻，事实并非如此

score 6 · Accepted Answer

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

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

另一方面，如果注销链接不应该位于底部，并将其移至顶部更正，则在您的消息之前使用“修复：”。

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

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

score 2 · Accepted Answer

常规提交规范的使命宣言是：

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

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

但是，这些都不意味着知道您要发布什么或您是否打算发布。

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

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

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

你为什么要做出这样的改变？

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

2 回答 2