DEV Community


Discussion on: 🔨 [git]: Write better commits with Gitmoji

moopet profile image
Ben Sinclair

I think this is a lot harder to read than text, and a lot harder to search for. I would never guess that "fire" meant "remove code" or that a coffin meant the same, and the different variations of things like tools and builders' hats aren't distinct enough.

This problem happens any time people try to use icons. They find one or two that seem to fit, and then run out of 1-to-1 matches so end up using generic things like "document" for everything else.

I don't relish having to search the web for something that looks like a bug emoji, copy it, paste it into my search box, and then discover than the other person working on the project used a slightly different bug.

jessekphillips profile image
Jesse Phillips

I agree but also disagree.

search the web for something that looks like a bug emoji [...] other person working on the project used a slightly different bug.

This can also be true with words, bug isn't the greatest example, though. In the case of gitmoji, the icons are being defined and there is a place to search on what you might want and still remain consistent across the team.

That being said, it isn't about the icons. It isn't really about reading or searching. It encourages good separation of intent for a commit.

I have a general rule that their is on emoji per commit. If the commit should have two then the commit should be broken apart. We don't want the code refactor and feature add at the same time. Yes I do break this from time to time, but this is an exception rather than common practice.

The emoji list goes a little further then necessary, but it also provides more opportunity to identify how to separate commits.

michaelcurrin profile image

Also worth noting is the gitemoji system is an extension or variation of the conventional commit system, which has fewer items. So there is less to remember and to choose from when writing messages.

Like two gitemoji choices for deleting plus the config change can go under chore for conventional commit.

And two CI choices can go under ci.

I also don't care about a separate item for "development scripts". I would put that feat or fix or refactor etc.

It depends what you agree in your team and how you are going to use it. Having granular messages (gitemoji and/or conventional commit) is useful if have a large number of commits to generate a changelog / release notes for, maybe even for end users to read to know fixes for their Android device.

But otherwise using just the conventional commit system without the emojis is fine. There is a VSCode extension which supports that word as a prefix without the emoji.

michaelcurrin profile image
Michael • Edited

I agree. I've seen other threads where someone doesn't understand what the emojis are.

I think a good middle -ground is using both. Maybe like this.

⚡ perf: Improve speed of function foo
Enter fullscreen mode Exit fullscreen mode
Forem Open with the Forem app