johannchopin
commented
4 years ago I really really love the idea of having a convention for gitmojis. Not one to be followed to the letter, but at least one attempt to orient the user.
IMHO there should be no scope gitmojis in the convention because that would mean adding a lot of emoji for all the scopes (Work about oracle, Work about nginx, ...), which would be overkill (see #435).
Adding a scope, which is mostly a filename file, don't seems to make sense to me. Rarely is there only one file that is modified by commit. If there is multiple files, what would the scope looks like? Something like that?
🏷️(interfaces.ts, interface2.ts): add type definition for EmojiReponseCommit message is then really hard to read in this case.
Moreover the scope (all the files) is already store in the commit itself and so this information is redundant.
I love the simple structure already mentionned by @carloscuesta in https://github.com/carloscuesta/gitmoji/issues/345#issuecomment-541311170:
<gitmoji> <comment>
- 🐛 #231
- 🚨 Use CamelCase
Lyokolux
carloscuesta
bruxisma
vhoyer
Hello all,
here is only a reflexion about creating a convention for commit messages using Gitmoji.
This should not be included in the gitmoji project; but should serve as help for people who wants to use gitmoji in a team. This is then a draft of how to use them well or at least a way to sort the gitmojis. Not all the gitmojis are included btw.
Motivation for a convention
The only problem is that gitmojis are not supported everywhere and thus, should be used when every members can read them.
Convention
The [Angular commit convention]() follow this rule
<type>(<scope>): <subject>and have proven that it works well. Gitmoji can match nearly this case:<type>can be replaced by<action>. "action" matches better the gitmoji definitions on the website.At least one gitmoji must be used for each commit
Sorting the gitmojis
Action (What ?)
Scope (Where ?)
Outsider
:hankey:, :beers:, :ok_hand:, ... but always funny to use
Translating the Angular convention
Examples
:clown_face:(idGenerator.ts): add mocks
:see_no_evil: ignore the dist directory
:camera_flash:(home.vue)
:label:(interfaces.ts): add type definition for EmojiReponse
:truck: id_generator.ts → IdGenerator.ts
:twisted_rightwards_arrows: feat/api-v1 → master
:twisted_rightwards_arrows: feat/api-v1 into master
:fire:(eslintrc.json): duplicate with eslintrc.js
:rotating_light:(store.ts)
:recycle:(:card_file_box:) : rename the field "age" in the table USER
Comments
As the new issue #435 is related, the project is defining emojis without specific goal. Some comments in the issue explain well how the gitmojis can be used. I think Gitmoji should be neutral (such as a dictionary; without opinion) and let people decide how to use the emojis.
Some gitmojis indicate implicitly the scope such as :heavy_plus_sign: or :see_no_evil:. Some provide the action and the scope such as :green_heart:
A placeholder for the effect of the commit on the project can be added too. I think specifically about the :boom: I don't use it and might be used at the end of the commit message ?
With this commit message pattern, some Gitmojis are ambiguous such as :wrench:. It does not provide a clear where, nor an clear action and mix both where and action and does not fit. They should be kept in Gitmoji but excluded in use for this convention.
Using more than one emojis make the message less readable IMHO; so using emojis for scope makes the commit harder to read. It is a possibility however. It opens the way to new gitmojis such as #321
This can be seemed as overkill and gitmojis should be kept simple anyway ! Maybe this is too much ?
So what do you think of it ? Is it to throw away; or to be improved and how ? I hope it makes the emojis less chaotic :)