🔨 [git]: Write better commits with Gitmoji

📝 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

...

Links

• https://emojipedia.org/laptop/

• https://gitmoji.dev/

• https://github.com/carloscuesta/gitmoji

• https://github.com/carloscuesta/gitmoji-cli

• https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716

• https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53

• https://gist.github.com/parmentf/035de27d6ed1dce0b36a

• https://dev.to/i5han3/git-commit-message-convention-that-you-can-follow-1709

• https://dev.to/helderburato/patterns-for-writing-better-git-commit-messages-4ba0

• https://chris.beams.io/posts/git-commit/

Comments

[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.

[Michael Currin]

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

[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.

[Michael Currin]

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.

[cblte]

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.

[Richard]

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.

[Jim Priest]

This is akin to putting HTML into email. Just... no.

[MV]

try :octocat: 🤓

[muzammilaalpha]

thanks for sharing

[John McElreavey]

Would be awesome to have something like this integrated into Gitkraken

[Roel Hogervorst]

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!

[James Bissick]

Gitmoji is a great find. Will definitely use it in upcoming projects.

[Beeblebrox]

Broke the build once by putting emoji, and build server (Bamboo) got completely stuck as it couldn't swallow that commit message... :/