如何根据常规提交规范对 UI 更改进行分类？
How to classify UI change according to the conventional commits specification?
基于 conventional commits 仅仅 UI 变化应该如何分类？例如，假设一个注销按钮从屏幕底部移到了顶部，在文本旁边添加了一个图标，并且有一个新的动画。除此之外，从功能的角度来看没有任何变化。
我的困惑来自这个（可能是错误的）推理。您不能使用以下任何一项，因为：
- 专长：这不是新功能
- 修复：没有任何错误需要修复
- perf：未涉及性能
- 重构：这可能是重构 Angular definition of refactor "A code change that neither fixes a bug nor adds a feature", but not using the Wikipedia definition 之后的情况“代码重构是重组现有计算机代码的过程——改变分解——而不改变其外部行为”
- style：不影响代码含义的更改（white-space、格式、缺少分号等）。事实并非如此
特征不需要很大。尽管代码更改非常小，但注销 link 的重定位是 user-facing，因此是一个功能。在提交中使用“feat”前缀是可以接受的。
feat: moved logout link to top of page, resolves #1234
另一方面，如果注销 link 不应该在底部，将它移到顶部更正了这一点，那么请在您的消息前使用“fix:”。
fix: moved logout link to top of page. Fixes #1234
您 link 提到的文章中提到了很多关于语义版本控制的内容，并且似乎更多地针对 API 而不是整个应用程序，因此不会存在对应用程序更改的准确翻译，但您可以做一些相关性。
常规提交规范的使命宣言是：
A specification for adding human and machine readable meaning to commit messages
然后其他工具可以使用该规范来确定变更集是否需要发布。
然而 none 是为了了解您要发布什么或您是否打算发布。
例如，其中一些工具不会发布仅包含 docs 或 style 类型提交的变更集。毕竟，更改私有函数的文档或将选项卡转换为 space 并不会真正影响您的最终用户。因此，该变更集将在您下次产生“有意义的”提交时发布。
然而，与几乎所有事情一样，上下文是关键:
在 NPM 库中，README 文件总是 包的一部分。如果存在事实错误或遗漏某些内容，您可能希望尽快交付该更改。所以 docs 类型的提交在这里可能不合适。也许这更像是 fix?
在 Git-managed 博客中，whitespace-only 更改实际上可能会提高内容的可读性。 feat 类型的提交会更适合这里吗？
你为什么要做出这样的改变？
正如我在上面试图说明的那样，上下文很重要。不要拿你看到的例子看表面价值。
您是否因为贵公司的 UI/UX 准则正在发生变化而做出此更改？这将是 feat 类型的提交恕我直言。 （可能是一个重大变化？）
您进行更改是因为 A/B 测试表明这对您的产品或用户来说是最好的更改吗？恕我直言，这将是 feat 类型的再次提交。
您进行更改是因为用户投诉他们看不到从哪里退出您的应用程序吗？这可能更像是 fix 类型的提交。
基于 conventional commits 仅仅 UI 变化应该如何分类？例如，假设一个注销按钮从屏幕底部移到了顶部，在文本旁边添加了一个图标，并且有一个新的动画。除此之外，从功能的角度来看没有任何变化。
我的困惑来自这个（可能是错误的）推理。您不能使用以下任何一项，因为：
- 专长：这不是新功能
- 修复：没有任何错误需要修复
- perf：未涉及性能
- 重构：这可能是重构 Angular definition of refactor "A code change that neither fixes a bug nor adds a feature", but not using the Wikipedia definition 之后的情况“代码重构是重组现有计算机代码的过程——改变分解——而不改变其外部行为”
- style：不影响代码含义的更改（white-space、格式、缺少分号等）。事实并非如此
特征不需要很大。尽管代码更改非常小，但注销 link 的重定位是 user-facing，因此是一个功能。在提交中使用“feat”前缀是可以接受的。
feat: moved logout link to top of page, resolves #1234
另一方面，如果注销 link 不应该在底部，将它移到顶部更正了这一点，那么请在您的消息前使用“fix:”。
fix: moved logout link to top of page. Fixes #1234
您 link 提到的文章中提到了很多关于语义版本控制的内容，并且似乎更多地针对 API 而不是整个应用程序，因此不会存在对应用程序更改的准确翻译，但您可以做一些相关性。
常规提交规范的使命宣言是：
A specification for adding human and machine readable meaning to commit messages
然后其他工具可以使用该规范来确定变更集是否需要发布。
然而 none 是为了了解您要发布什么或您是否打算发布。
例如，其中一些工具不会发布仅包含 docs 或 style 类型提交的变更集。毕竟，更改私有函数的文档或将选项卡转换为 space 并不会真正影响您的最终用户。因此，该变更集将在您下次产生“有意义的”提交时发布。
然而，与几乎所有事情一样，上下文是关键:
在 NPM 库中，README 文件总是 包的一部分。如果存在事实错误或遗漏某些内容，您可能希望尽快交付该更改。所以
docs类型的提交在这里可能不合适。也许这更像是fix?在 Git-managed 博客中，whitespace-only 更改实际上可能会提高内容的可读性。
feat类型的提交会更适合这里吗？
你为什么要做出这样的改变？
正如我在上面试图说明的那样，上下文很重要。不要拿你看到的例子看表面价值。
您是否因为贵公司的 UI/UX 准则正在发生变化而做出此更改？这将是
feat类型的提交恕我直言。 （可能是一个重大变化？）您进行更改是因为 A/B 测试表明这对您的产品或用户来说是最好的更改吗？恕我直言，这将是
feat类型的再次提交。您进行更改是因为用户投诉他们看不到从哪里退出您的应用程序吗？这可能更像是
fix类型的提交。