为何Conventional Commits无“update:”类型？需始终用“feat:”吗？

为什么规范里没有预设"update:"类型 #

Conventional Commits的核心是语义化的提交分类，它把各种"更新"场景拆分成了更精准的内置类型，而非用笼统的"update"：

• feat: 对应功能层面的更新——不管是新增功能，还是对现有功能的实质性增强（比如给搜索框加防抖逻辑），本质都是功能迭代，归为feat更能体现提交的价值
• fix: 对应bug修复类的更新——修复现有功能的逻辑错误、边界问题，这类更新的目的是解决问题，用fix更清晰
• 除此之外还有docs:（文档更新）、style:（代码格式调整）、refactor:（无功能变更的代码重构）等类型，分别对应不同场景的"更新"。如果用模糊的"update:"，会丢失提交的语义信息，也会让依赖规范的工具（比如自动生成CHANGELOG、版本号自动升级）无法准确识别提交的影响范围。

能不能自定义添加"update:"类型 #

当然可以。Conventional Commits本身是约定式规范，而非强制的语法约束，只要团队内部达成一致，完全可以扩展自定义类型：

• 先明确适用场景：比如团队遇到一些无法用现有类型覆盖的小更新（例如同时微调了配置文件和 README 内容，且不属于任何单一内置类型的场景），可以约定update:仅用于这类跨场景的轻量更新
• 同步工具配置：如果你们使用了semantic-release这类依赖规范的工具，需要在配置文件中声明自定义类型的影响级别（比如是否触发版本升级），避免工具无法识别
• 避免滥用：自定义的update:不能成为"万能类型"，必须有明确的边界，否则又会回到语义模糊的问题上，违背Conventional Commits的初衷

内容的提问来源于stack exchange，提问作者mrdoubleu