![Cover image for 🔨 [git]: Write better commits with Gitmoji](https://media.dev.to/cdn-cgi/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fv6sayrf35j4be2ehuyk5.png)
📝 Notes
Gitmoji is an initiative to standardize and explain the use of emojis on GitHub commit messages.
📝 Intro : How to Wr...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
I agree but also disagree.
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.
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
chorefor 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.
Hey, there. This is really nice. I like it.
I will use it while reading the gitbook about golang and tests.
Come in quite handy. And the CLI is nice to use. Like the interactive commit options.
And for all the others:
You probably dont know, but the commit message is NOT using en emoji directly copy pasted. It will insert the already exisitng github
:smile:emoji format with colons. So to other screens it just looks like text and not like some unicode gibberish.It really depends on the client and service if they render the
:smile:,:robot:,:thumbs-up:thingy or not.I like this in principle. It speaks to the side of me that enjoys order and rules. But I can see where this steps into the realms of layering up a process and overcomplicating things.
I can see this working in a small closed team environment, where there is a lot of emphasis on house rules. I think where this loses appeal for me is longevity and larger or more open-source projects. I think for the sake of reading through a large number of commits from hundreds of different contributors, a word-based system, or a hybrid system would work better (as suggested in other comments before mine.)
I'm not keen on overcomplicating rules for fleeting contributors. I do really like how it looks though and I'd use it for personal and smaller/private projects.
As with any tool, gotta ask yourself is it appropriate for what you're doing.
This is akin to putting HTML into email. Just... no.
try :octocat: 🤓
thanks for sharing
Would be awesome to have something like this integrated into Gitkraken
I've used this and I really like templated step by step commits so you don't forget stuff. The emoji make it easy to see what happened when. But I feel there are too many options to choose from!
Gitmoji is a great find. Will definitely use it in upcoming projects.
Broke the build once by putting emoji, and build server (Bamboo) got completely stuck as it couldn't swallow that commit message... :/
I'm not sure you understand how Conventional Commits are supposed to work. This is not an example of one:
<feat> [home, components]: Add login buttonThis is how that should be written in a real commit example:
feat(home, components): add login buttonThe angled brackets are an indication of "required", not something you're supposed to type.
Hi Johnny, this comment comes off as aggressive and doesn't add anything to the discussion. Please, review the Dev.to Code of Conduct.
This post is a custom solution that appears to be loosely based on the Conventional Commits format, since it uses emojis instead of plain text. However, this correction isn't accurate. The examples the author used include square brackets like the documentation shows.
It wasn't my intention to come off as aggressive. I took the time to point out a mistake in the article. I don't see how you can say it "doesn't add anything to the discussion". That comes off as totally disingenuous.
Please scroll down to the Examples section in the link you provided. I took the time to research before I posted, including looking at the commit history of several repositories that listed as examples of projects that follow this pattern.
Ahh, interesting. So, the author isn't following that pattern at all. Generally speaking, e.g. in Bash, square brackets indicates an optional parameter. Both the conventional commits format and the gist they linked to doesn't stick to that standard.
Yeah, it's a bit confusing isn't it? They're linking to a pattern as an example to follow, but not following it in their examples. I don't get it.
That is odd.
Kudos for pointing out a potential typo! Let's aim for a more passive voice when pointing them out in the future.
Cheers!
Hi,
I am sorry for the confusion.
Thanks to Johnny and Forest for the correction and the reactivity.
I will update the post with the correction.
Javid.
@foresthoffman Let's aim for less trigger-happy reactions and condescension, and maybe assuming good intentions, while we're at it.
No worries, Javid! Keep up the great work :)
I appreciate that your intention wasn't to be aggressive. My interpretation of the original comment, "I'm not sure you understand how Conventional Commits are supposed to work. This is NOT an example of one", was not one of tactful criticism. Therefore, I expressed that the comment could be interpreted as aggressive. The original comment didn't include the link that you later provided, which points out that there was a disconnect between what was in the article and the documentation being linked to.
New accounts are joining dev everyday, and sometimes a comment like this pops up. I of course didnt mean any personal offense. I'm just one of many members that want to ensure that there's an even playing field of constructive criticism and positivity.
Have a good one!