Best approach of how to manage many conventional commits of type feat on one feature branch

[codebydant]

Hi @PaulHatch,

I hope you find very well.

I wanted to open this discussion since I think this a really important topic to cover in order to get the full potential of the semantic-version action.

I've been added to a repo that uses the Conventional Commits specification.

If I was to create a feature/A branch that contains a new feature, does that mean every single commit I make should have a committed structure of feat: my message related to this commit, or should I only have 1 feat commit and the rest chore or another type which does not bump up the version of the repo/module? (this is because we can add multiple features in the same feature branch)

Or do I not need to worry about that as the branch is feature/A and therefore semantic-version knows to bump the package up by 1 minor version as it's in a feature branch?

Hopefully the above makes sense, but if not here is a commit history example:

feat: add product card basic layout
feat: add title to product card
test: add unit tests to product card
feat: add image to product card
chore: update breakpoints for card
test: add more unit tests

Would this example above bump the module up by 3 minor versions as I've used feat 3 times, or one it only bump by 1 minor version since this is a feature branch? Or does this not matter and the only thing that matter is squashing the commits and ensuring feat: added product card for example is the squashed commit message?

Or should we define the merged commit with a conventional type message such as

feat: Merged feature branch to main

Merge or rebase

What strategy would be better for this case, should we use rebasing or merging the new feature branch into the main branch?

Related post

• https://stackoverflow.com/questions/64812270/many-conventional-commits-of-type-feat-on-one-feature-branch
• https://stackoverflow.com/questions/61249210/commit-type-before-feature-is-done

[PaulHatch]

One point of possible clarification--this action does not look at branches to determine the change type, only commit messages. This action works as a pipeline of composed providers and formatters, each of which is responsible for a specific task. These tasks are:

• Get the current commit
• Determine the last release
• Gather a list of all the commits in the last release
• Classify the release based on all the information collected

In any case, the version is only going to be incremented by 1, so if the last release identified was 1.2.3 the output is going to be 1.2.4, 1.3.0 or 2.0.0, and it is going to stay that way on subsequent commits until a new release is created using either a tag or a branch (or if you have bump_each_commit set to true, every commit will be considered a release, which is intended for very small projects that do not have any sort of post release gates like QA or UAT and are always released on every commit. In general I do not use them, but it is a better option than attempting to have the build itself create the tag, which can lead to race conditions.)

The branches are considered only if you choose use_branches, in which case the last release is determined by using the highest branch instead of tag. From there, the commit identified as the "last release" is passed along to the next step which collects a list of commits, which in turn are passed to the version classifier, which neither knows nor cares whether these commits were obtained using a branch or a tag.

Note that even if branches are used in this process, the branches we are concerned with are version branches. In your example of feature/A, that's not something that this action is going to even look at. It would only being looking at branches like release/v1.2.3.

Also In general I do not recommend using branches unless you need to maintain ongoing releases of multiple versions. This is something usually only done by vendors or larger projects with external users which might have a version 2.x.x and 3.x.x both receiving ongoing updates at the same time. For most projects that you run yourself or only maintain one current definition of "latest" this is just adding unnecessary complexity.

[PaulHatch]

^ and to answer what I think was your main question, you do not need to mark each commit, as any commit appearing in the list will be considered applicable for the entire release. Furthermore, the most significant commit type will be used as the type for the release. In other words, if you have two "minor" changes and one "major" change, the type will be major, since that commit is going to introduce breaking changes to the release regardless of how many other minor changes are introduced along with it.