Conventional commits. How to avoid fixes in release notes during feature development

Question

Just trying to understand how to work with semantic releases. I use node release-it library, but I don't think it matters. Question is general about semantic releases and commits.

So... For example I have a juicer which can make an apple juice. It was released as version 1.0.0. Then I decided to add ability to make orange juice and lemon juice (will be in 1.1.0). It will be two feat commits. And after I finished development, but before making a new release I found an issue in one of the new features. If I use fix commit when I fix it, then automatic release notes generator will add it into "Bug fixes" section. But this bug never existed, because feature never released.

What is a right way to fix issues in non-released features?

Answer 1

I confess I've never used conventional-commits, however, based on the linked spec in the tag definition, I think you can extrapolate from this suggestion:

What do I do if I accidentally use the wrong commit type?

When you used a type that’s of the spec but not the correct type, e.g. fix instead of feat

Prior to merging or releasing the mistake, we recommend using git rebase -i to edit the commit history. After release, the cleanup will be different according to what tools and processes you use.

In your scenario you have not released yet when fixing one of your feat bugs, and so I would interpret the above as implying you can use interactive rebase in this case also, to squash your bug fix into the original feat commit.

If for some reason rebasing is undesirable, then perhaps you can use a different type:

types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

or even a purposefully undefined type, such as misc: or fixup:, which is allowed:

When you used a type not of the spec, e.g. feet instead of feat

In a worst case scenario, it’s not the end of the world if a commit lands that does not meet the Conventional Commits specification. It simply means that commit will be missed by tools that are based on the spec.