Confusion about the extent of feat #86

New Issue

GiteaMirror · 2026-02-17T11:44:08-06:00

GiteaMirror commented

2026-02-17 11:44:08 -06:00

Originally created by @CrispyDrone on GitHub (Oct 22, 2019).

Hello,

When I implement a new feature, it might be necessary or natural to also:

refactor something to be able to support the new feature
update documentation about the new feature
update a build definition
write more tests
change code formatting

Currently the general trend is to squash merge features (#38) to have a clean commit history. However this means, that all of my carefully crafted intermediary commits with chore, docs, style, refactor,... will go to waste.

It also means that a single feat will do more than just introduce a new feature, which is misleading.

There was some nice discussion in issues #26 and #78 but it didn't settle this dilemma for me.

It seems to me that feat has a broad definition:

feat: a commit of the type feat introduces a new feature to the codebase for the end-users of 
your product / library (this correlates with MINOR in semantic versioning).

so maybe it isn't a problem to have feat be an amalgamation of all kinds of commits? Or what is the official recommendation of the spec?

Originally created by @CrispyDrone on GitHub (Oct 22, 2019). Hello, When I implement a new feature, it might be necessary or natural to also: + refactor something to be able to support the new feature + update documentation about the new feature + update a build definition + write more tests + change code formatting Currently the general trend is to squash merge features (#38) to have a clean commit history. However this means, that all of my carefully crafted intermediary commits with `chore`, `docs`, `style`, `refactor`,... will go to waste. It also means that a single `feat` will do more than just introduce a new feature, which is misleading. There was some nice discussion in issues #26 and #78 but it didn't settle this dilemma for me. It seems to me that `feat` has [a broad definition](https://github.com/conventional-commits/conventionalcommits.org/issues/26#issuecomment-349796791): ``` feat: a commit of the type feat introduces a new feature to the codebase for the end-users of your product / library (this correlates with MINOR in semantic versioning). ``` so maybe it isn't a problem to have `feat` be an amalgamation of all kinds of commits? Or what is the official recommendation of the spec?

GiteaMirror closed this issue

2026-02-17 11:44:09 -06:00

GiteaMirror commented

2026-02-17 11:44:10 -06:00

@damianopetrungaro commented on GitHub (Oct 23, 2019):

You can still merge a PR with multiple commits (not squashed) in order to have all your commits in place right?

PR: Add feature X
- feat: describe feature X here
- chore: describe dummy change related to that feature here
- test: update some test, this should be in the same in the "feat" IMHO
- docs: update your documentation with the new feature X

Am I missing something?

@damianopetrungaro commented on GitHub (Oct 23, 2019): You can still merge a PR with multiple commits (not squashed) in order to have all your commits in place right? - PR: Add feature X - feat: describe feature X here - chore: describe dummy change related to that feature here - test: update some test, this should be in the same in the "feat" IMHO - docs: update your documentation with the new feature X Am I missing something?

GiteaMirror commented

2026-02-17 11:44:11 -06:00

@CrispyDrone commented on GitHub (Oct 23, 2019):

Hi,

Thank you for your response.

I'm sorry my question wasn't that clear. It wasn't necessarily about having a pragmatic solution, there are different solutions out there.

My question is more about the extent of the feat commit type according to the specification and what the specification seems to recommend i.e. separating commit types as much as possible.

To me it seems that feat can quite easily contain all kinds of other commit types; even though you update documentation, it's documentation for that feature, and it doesn't make much sense to separate it from the actual feature. Same for the refactoring, it is tightly connected to the feature. As a consequence of introducing a new feature that necessitated some refactoring, you might even fix a bug.

What does the specification say about these scenarios, is it ok to just have the feat commit introduce all these changes because in essence they are part of the package you call a new feature, or should we indeed keep them separate?

@CrispyDrone commented on GitHub (Oct 23, 2019): Hi, Thank you for your response. I'm sorry my question wasn't that clear. It wasn't necessarily about having a pragmatic solution, there are different solutions out there. My question is more about the extent of the `feat` commit type according to the specification and what the specification seems to recommend i.e. separating commit types as much as possible. To me it seems that `feat` can quite easily contain all kinds of other commit types; even though you update documentation, it's documentation for that feature, and it doesn't make much sense to separate it from the actual feature. Same for the refactoring, it is tightly connected to the feature. As a consequence of introducing a new feature that necessitated some refactoring, you might even fix a bug. What does the specification say about these scenarios, is it ok to just have the `feat` commit introduce all these changes because in essence they are part of the package you call a new feature, or should we indeed keep them separate?

GiteaMirror commented

2026-02-17 11:44:13 -06:00

@JeanMertz commented on GitHub (Oct 23, 2019):

To me feat represents something that adds "customer" value to your code, so even though you might also add documentation, do some refactor work, and add tests to validate a new feature, all of which are part of the bigger unit of "all things required to get this in a shippable state", those are not part of the feat commit(s).

The GitHub PR (or whatever mechanism you are using) is which combines all these separate commits with their own problem domains into a single package signalling the intent that "this documentation commit, and these test commits go hand-in-hand with these feature commits".

The whole point of the convention described is precisely to split up these changes into smaller units, and create multiple commits where you would've written a single commit before including both the documentation, the tests and the feature.

It's good practice to commit your tests first anyway, as that allows you to get in the habit of test-driven design where you let the CI fail with your newly added tests, and then validate that those tests are green after pushing the feat commit.

Similarly, it makes sense (in my opinion) to write documentation first, to practice some form of "documentation driven design" to allow you to think up front about what you are going to build as you write out your thoughts in plain English.

But, some things work for some, but not for others, which is also why this is called a convention and not a set of hard rules you have to follow, see what works for you, but don't let your productivity be constrained by what the spec in this repository says, see if it helps you think differently about the way you code, and if that different way of coding does not suit you, look for some other best-practice that fits your style (or that of your company) better.

@JeanMertz commented on GitHub (Oct 23, 2019): To me `feat` represents something that adds _"customer" value_ to your code, so even though you might also add documentation, do some refactor work, and add tests to validate a new feature, all of which are part of the bigger unit of "all things required to get this in a shippable state", those are not part of the `feat` commit(s). The GitHub PR (or whatever mechanism you are using) is which combines all these separate commits with their own problem domains into a single package signalling the intent that "this documentation commit, and these test commits go hand-in-hand with these feature commits". The whole point of the convention described is _precisely_ to split up these changes into smaller units, and create multiple commits where you would've written a single commit before including both the documentation, the tests and the feature. It's good practice to commit your tests first anyway, as that allows you to get in the habit of test-driven design where you let the CI fail with your newly added tests, and then validate that those tests are green after pushing the `feat` commit. Similarly, it makes sense (in my opinion) to write documentation first, to practice some form of "documentation driven design" to allow you to think up front about what you are going to build as you write out your thoughts in plain English. But, some things work for some, but not for others, which is also why this is called a _convention_ and not a set of hard rules you have to follow, see what works for you, but don't let your productivity be constrained by what the spec in this repository says, see if it helps you think differently about the way you code, and if that different way of coding does not suit you, look for some other best-practice that fits your style (or that of your company) better.

GiteaMirror commented

2026-02-17 11:44:14 -06:00

@CrispyDrone commented on GitHub (Oct 25, 2019):

Hello,

Thank you for your response.

It has helped clarify the intent of the feat commit. I think that I will indeed have to reconsider the automatic squash based pull requests workflow, while also promoting the separation of commits as much as possible.

@CrispyDrone commented on GitHub (Oct 25, 2019): Hello, Thank you for your response. It has helped clarify the intent of the `feat` commit. I think that I will indeed have to reconsider the automatic squash based pull requests workflow, while also promoting the separation of commits as much as possible.

GiteaMirror referenced this issue

2026-02-17 11:57:15 -06:00

[PR #86] [MERGED] Remove 'NOT recommended' wording from the 'Other types' paragraph discussing breaking changes #280

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#86