How can I write good Conventional Commit-style commit messages for one feature over multiple commits?

Question

If I am working on a single feature, I would usually commit multiple commits. Should every commit start with feat? Or should only 1 commit have the type of feat and use a different type for the other commits?

e.g:

feat: add part 1
test: add part 1 test
feat: add part 2
fix: something in p2
feat: add part 3

Answer 1

Looking at the current specification for Conventional Commits, I don't see anything that explicitly identifies what to do in this case. However, I do see a few things that lead me to draw some conclusions on what the best thing to do is.

Conventional Commits are designed to work with Semantic Versioning. A commit identified as feat corresponds to a minor version, a fix commit corresponds to a patch version, and a BREAKING CHANGE represents a major version.

I would first want to understand your branching strategy. If you are committing to trunk, my advice would be different than if you are following Git Flow or GitHub Flow and developing in feature branches.

If you are using feature branches, it doesn't matter. The version number wouldn't increment until after at least one feature branch was merged into the main branch and you could increment the appropriate version once based on the set of commits.

If you are also using feature branches, I'd even suggest editing your commit history or squashing the commit into a single commit of the appropriate type when merging it into the main branch. Perhaps the commit history is useful when reviewing the code (such as during a pull request), but it becomes far less useful once the changes are integrated and you won't work with the individual commits but the change as a whole.

However, if you are committing to the main branch, you may not want your version to increment after every commit and until the feature is complete and I would suggest introducing a new type for the work-in-progress commits and then using feat when the feature is ready to be enabled in one or more environments. I would even be hesitant to use fix for changes that are not ready to be enabled to prevent incrementing the version of software for things that are not ready to be seen by users.

Your release and deployment frequency also play a part here.

If you are practicing continuous deployment, you are going to want to keep track of each set of code. You may choose to only increment the version when there's something new to be enabled and use the commit hash to keep track of which set of code is deployed. Or you may choose to increment the version on every deployment.

If you are bundling commits into planned releases, you can look at the full set of work to decide what version number to increment. Understanding what fixes, features, and breaking changes are part of the released code will affect the version number for the new build.

Of course, if you aren't using Semantic Versioning and are instead using some other versioning scheme, perhaps the nuances of Conventional Commits aren't appropriate for you since you don't need a signal about when to increment which parts of the version identifier. Your team can develop your own rules.