语义化发布：如何避免未发布功能的修复被纳入发布说明？

核心原则 #

未对外发布的功能问题不属于正式版本的Bug，本质是开发中功能的迭代修正，不需要用fix提交，避免污染发布日志的Bug修复板块。

具体处理方式 #

1. 改写/合并原feat提交（推荐） #

• 若未推送到远程仓库，直接执行git commit --amend修改原有feat提交内容，把修复逻辑整合进去，最终保持一个对应新功能的feat提交。
• 若已推送到远程且团队协作允许，可通过git rebase -i合并相关的feat和修复提交，将修复内容合并到原feat提交后强制推送（操作前需和团队同步沟通）。

2. 使用refactor或chore提交 #

如果不想修改历史提交，用以下提交类型标记修复：

• refactor: 修复橙汁制作功能的逻辑错误：适合调整功能实现逻辑的修复场景
• chore: 修正柠檬汁功能的参数问题：适合非核心逻辑的小调整场景

这类提交不会被发布笔记生成器归类到Bug修复板块，符合未发布功能的修正定位。

3. 自定义前缀标记（特殊场景） #

如果团队有自定义提交规范，也可以用自定义前缀，比如fix-in-dev: 修复未发布的橙汁功能问题，同时在release-it配置中过滤这类前缀，避免其出现在正式发布日志中。

补充说明 #

语义化发布和提交规范的核心是准确反映对已发布版本的影响，未发布的功能仍处于开发迭代阶段，其问题修复不影响已对外交付的版本，因此无需使用fix这个针对已发布Bug的提交类型。

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