何时使用“chore”作为提交消息的类型？ [已关闭]

Question

chore

在语义版本控制提交消息中有什么用？其他类型如 feat 或 fix 很清楚，但我不知道何时使用“chore”。

任何人都可以提供几个其使用示例吗？

另一个可能不相关的问题：修改像

.gitignore

这样的文件的提交消息的正确类型是什么？

Answer 1

你可以在“Git Commit Msg”中看到一个简短的定义：

chore

：更新grunt任务等；没有生产代码更改

它用于：

• “语义提交消息”和

• 项目“

  fteem/git-semantic-commits

  ”。

     git chore "commit-message-here" -> git commit -m 'chore: commit-message-here' 
  

修改

.gitignore

将是“杂务”的一部分。

“

grunt task

”意味着外部用户不会看到任何内容：

• 实现（现有功能，不涉及修复），
• 配置（如

  .gitignore

  或

  .gitattributes

  ），
• 私有内部方法...

虽然Owen S在评论中提到：

查看您链接到的Karma页面，我怀疑

grunt task

可能特指Javascript的构建工具

grunt

。
在这种情况下，他们可能没有想到涉及实现或私有内部方法的更改，而是工具更改、配置更改以及对根本不实际投入生产的事物的更改。
（我们的商店目前使用它来实现这些目的，也用于简单的重构。）

---

2024 年：常规提交规范引用了Angular 约定，因为 Angular 项目有许多以

chore(...):

开头的提交示例。

chore

定义为：

杂务：不修改

src

或

test

文件的其他更改。

然而，在 2020 年，conventionalcommits.org 问题 303 问道：

您对不推荐杂务提交类型有何看法，因为它已在 2017 年从 Angular Convention 中删除？

Angular 提交确实包括：

请注意，此 PR 删除了对“杂务”的支持，而“杂务”之前被团队中的每个人过度使用。