arvinxx / gitmoji-commit-workflow

😉 Gitmoji Commit Workflow
MIT License
220 stars 27 forks source link

gitmoji and subject are somehow redundant #18

Open hans-lizihan opened 3 years ago

hans-lizihan commented 3 years ago

originally in gitmoji 1.0, you use enum-type to enforce usage of gitmoji, that works great and I really enjoyed it.

Now in 2.0, it seems commitlint-config-gitmoji not only enforces on the gitmoji, but also on the subject in coventional-commit, i think this is a bit redundant.

e.g.

:bug: bug: Fixed a bug

git gitmoji has already indicated that the subject of this commit message is a bug, extra subject bug: is just way too tedious.

i'd recommend to provide some configuration options to restore behavior of usage of only gitmoji without extra enum type being passed in.

e.g.

:bug: Fixed a bug

or with scope

:bug:(feature) Null pointer bug in the feature
arvinxx commented 3 years ago

Thanks for your favor of this project and recommendation, I will try to figure it out to see whether can add this confuration.😄

And duration these time if you still want the previous version, you can lock the version of commitlint-config-gitmoji to 1.x.😉

Beside, I want to explain the reasons why I add the commit type check rule.

Firstly, the reason i add type check rule is that gitmoji is ambiguous, though it can indicated that the subject of this commit message. For example the :children_crossing: gitmoji, if you use this gitmoji without commit type, which commit type should it come to? a new feature? fix of some bug? Or a style thing? That's will be a huge problem when integrating with conventional-changelog or semantic-release.

And this's the second reasion to add commit type: to automatic manage version and to gernerate changelog. smantic version show a good pratice to manage the project version, so how about integrating it with gitmoji? And then there's the problem, if we can't figure out the core commit type, we can't integrating with semantic-release,which parsing commit type to estimate version and process the all workflow.

These two reason make me decide to add angular-commit style part to gitmoji commit style.(That's also a breaking change) Base on that I build the whole automatic workflow(I call it gitmoji-commit-workflow).

e1en0r commented 3 years ago

I can understand the reason for this redundancy in order to use the text type to determine the changelog category, but I think what adds to this redundant feeling is the original commit message gitmoji being stripped out when generating the changelog. This sort of defeats the purpose of having it in the first place.

With that said I would love for the changelog to include the gitmoji in the message. The text type would act at the major changelog header as it does now, and then the emojis would act as sort of a subcategory.

So a series of commits like this would end up like the changelog posted below

:zap: feat: improve button performance
:lock: fix: fix security issue in button
:bug: fix: fixed button click event
:lipstick: feat: improved the button styles
:sparkles: feat: added a new button

1.1.0 (2021-03-29)

Features

* ⚡️ improve button performance (hash)
* 💄 improved the button styles (hash)
* ✨ added a new button (hash)

Bug Fixes

* 🔒 fix security issue in button (hash)
* 🐛 fixed button click event (hash)
ImBIOS commented 1 year ago

How can we achieve this? I love gitmoji style but I didn't like it when I should use the type. Is there any rules I should set?

rdbisme commented 1 year ago

This commitlint.config.js allows the commit without the subject and type:

module.exports = {
  extends: ["gitmoji"],
  rules: {
    "type-empty": [2, "always"],
    "subject-empty": [2, "always"],
  },
};