![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 Write a Git Commit Message
In my case, I only read commits when i would like to track commit changes or to dig commit explanation. Otherwise, I directly read the source code.
Here is an example of good git commit message semantic will look like (according to Gist Semantic Commit Messages)
<type> [scope]: "Message"
type must be one of the following mentioned below :
- <build>: Build related changes (eg: npm related/ adding external dependencies)
- <chore>: A code change that external user won't see (eg: change to .gitignore)
- <docs>: Documentation related changes
- <feat>: Introduction of a new feature
- <fix>: Resolve an issue directly linked to development (bugfixes)
- <hotfix>: Resolve an issue directly linked to production (patches)
- <test>: Add/Update test cases
- <performance>: Add code that improves performance
- <refactor>: Update for code for maintainability (clean code)
scope is optional and must be a noun that represents the section of the codebase
Message should be imperative and should describe the commit with a clear message/keywords.
Example of commits :
feat(home, components): Add login button
feat(home, components): Add login modal
fix(home, components): Resolve issue with modal collapses
chore(home): Move icons folder
feat(newsletter): Add Newsletter component
feat(navbar): Add navbar container
🚀 Gitmoji
Using emojis on commit messages provides an easy way of identifying the purpose or intention of a commit with only looking at the emojis used. As there are a lot of different emojis I found the need of creating a guide that can help to use emojis easier.
Now we can replace the <type/> with an emoji :
🎨 Improve structure / format of the code.
⚡️ Improve performance.
🔥 Remove code or files.
🐛 Fix a bug.
✨ Introduce new features.
📝 Add or update documentation.
🚀 Deploy stuff.
💚 Fix CI Build.
👷 Add or update CI build system.
🔧 Add or update configuration files.
🔨 Add or update development scripts.
⚰️ Remove dead code.
Example of commits :
✨ (home, components): Add login button
✨ (home, components): Add login modal
🐛 (home, components): Resolve issue with modal collapses
🚚 (home): Move icons folder
✨ (newsletter): Add Newsletter component
✨ (navbar): Add navbar container
🔥 (navbar): Remove old navbar file
✅ (home): Add login test case
🎨 (home, component): Improve login modal
📦️ (npm): Add react-table
🔨 Update script start-server.js
Additionnal icons
🐳 Add Dockerfile
🐳 Add docker-compose.yml
☸️ (helm): Add postgres helm chart
☸️ (helm): Update frontend.yaml
☸️ (helm): Update pvc.yaml
🐎 (home): Increase speed load for navbar
🍎 (home): Fix issue with MacOS for navbar
Link: EmojiPedia
📦️ Gitmoji-CLI
A gitmoji interactive client for using gitmojis on commit messages.
Installation
With npm :
npm install gitmoji-cli
On MacOS :
brew install gitmoji
Interactive Client
Start the interactive commit client, to auto generate your commit based on your prompts.
gitmoji -c
Hook
Run the init option, add your changes and commit them, after that the prompts will begin and your commit message will be built.
gitmoji -i
git add .
git commit
Search
Search using specific keywords to find the right gitmoji.
gitmoji -s "criteria"
List
Pretty print all the available gitmojis.
gitmoji -l
Config
Run gitmoji -g to setup some gitmoji-cli preferences.
gitmoji config
🔨Extensions (Integration with IDE)
Gitmoji for Vscode
Link : https://marketplace.visualstudio.com/items?itemName=Vtrois.gitmoji-vscode
Gitmoji for Atom
Go to Settings (cmd + , or ctrl + ,) > Install and search for gitmoji-atom.
Alternatively, run the following command:
apm install gitmoji-atom
Link : https://atom.io/packages/gitmoji-atom
💻 Integration with DEV.TO ?
Do you think that we can use it while writing posts for Dev.TO ?
🐳 Docker
☸️ Kubernetes
...
Latest comments (23)
Would be awesome to have something like this integrated into Gitkraken
Gitmoji is a great find. Will definitely use it in upcoming projects.
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.
thanks for sharing
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.This is akin to putting HTML into email. Just... no.
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!
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!
try :octocat: 🤓
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.
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.
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.