Semantic commit type when remove something

Question

What semantic commit type is better to use, when I remove a feature: feat, refactor or something else?

Acrobat

Answer 1

you should use refactor,

• feat: introduces a new feature to the codebase
• fix: patches a bug in your codebase
• refactor: A code change that neither fixes a bug nor adds a feature

you can refer to angular/CONTRIBUTING Commit Message Guidelines

Verdi

If I delete a unit test project + its source code, is that test:? Or still refactor:? – Metallic

If refactor means refactoring, it would be wrong to use it. Refactoring means improving the code without modifying the existing functionality. – Donate

@void.pointer, I use feat, fix and refactor for changes made in the shipping code. I use test for any change in the tests, docs for any change in the documentation. – Donate

Refactor is for changes that do not introduce any changes in the feature set. Or system behavior. It is written as "adds a feature", but the code does not have to strictly have more bytes than before. From the product owner's perspective, sometimes removing things, even (old?) features, is a (new) feature. Busineses change with time, so do features. 3 years ago, I added "handle SWIFT transfers to Russia". It was a new feature. Lately I removed this code, because "ignore SWIFT transfers to Russia" is the new top-scored requirement. Removing code turned out to add a feature of the system. – Gluttonize

This is the correct answer: https://mcmap.net/q/379054/-semantic-commit-type-when-remove-something – Henrik

Answer 2

Use feat when you add or remove a feature.

According to wikipedia, "code refactoring is the process of restructuring existing computer code without changing its external behavior".

If you remove a feature you change code behavior so it can not be a refactor.

Jello

Answer 3

By definition, it is refactor, since:

refactor: A code change that neither fixes a bug nor adds a feature

Removing a feature is certainly a code change, and it neither fixes a bug nor adds a feature.

However, people usually have an assumption that refactor tends to not introduce breaking changes. And removing a feature tends to always break the API, since a feature is removed from the API, and this breaks all existing system depending on that feature.

What about other types? Absence of a feature itself may be considered as a feature. For example, if someone dislike the idea of password login (it is annoying to input a password every time to login), then they may consider not having the feature of password login as a feature. Thus removing a feature can be considered as adding a new feature.

At the same time, if an absence of a feature itself may be considered as a feature, then the existence of that feature may be considered as a bug. So removing a feature may be considered as fixing a bug. Thus removing a feature is both feat and fix.

Alternatively, we can pretend that the problem does not exist. A well designed library should not have an unwanted feature. And since other libraries and applications may depend on this feature, features should never be removed. But this ideal principle does not apply to every library.

So my suggestion is giving this type of commit a new name.

Equipage

It may not fix a bug, but it does fix some issue (e.g. improves UI, or removes obscure feature requiring too much code complexity to support). So, if one doesn't want to introduce a new prefix, I think fix is a good default. On the other hand, there is also refactor!: ... with an exclamation mark to denote breaking changes. – Stochmal

Your answer starts with an incorrect statement, followed by a long explanation why it's incorrect, but I think most ppl that come here will only read the first line... – Henrik

Removing a feature is the same as adding a feature but with negative sign. – Jello

Answer 4

Exclamation marks can be used to denote breaking changes. Removing a feature is a breaking change. Thus, there is refactor!:

refactor!: a BREAKING CHANGE that neither fixes a bug nor adds a feature

Stochmal

Answer 5

Use refactor,because you reconstruction your code. like:

refactor(core): Add warning when signal equality is false for object

There is a reference about Git Commit Msg for you

Addy

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Cascabel