I love gitmoji and I we have been using them for a while (well... I kinda forced my staff...). However, it is tedious to always scan for the right gitmoji given a certain context.
Following the gitflow approach
// =============================================================================
// Mangage...
// =============================================================================
// ...delivery
๐ Initial commit. - (:tada:)
๐ Releasing / Version tags. - (:bookmark:)
๐ Deploying stuff. - (:rocket:)
๐ Merging branches. - (:twisted_rightwards_arrows:)
โช Reverting changes. - (:rewind:)
๐ Writing docs. - (:memo:)
๐ Adding or updating license. - (:page_facing_up:)
// ...value
๐ Adding analytics or tracking code. - (:chart_with_upwards_trend:)
๐ Internationalization and localization. - (:globe_with_meridians:)
๐ฌ Updating text and literals. - (:speech_balloon:)
โฟ Improving accessibility. - (:wheelchair:)
// ...infrastructure
๐ Performing database related changes. - (:card_file_box:)
๐ณ Work about Docker. - (:whale:)
// ...integration
๐ท Work on CI build system. - (:construction_worker:) // "Work on" instead
๐ Fixing CI Build. - (:green_heart:)
// =============================================================================
// Create...
// =============================================================================
// ...features
โจ Introducing new features. - (:sparkles:)
๐ง Work in progress. - (:construction:)
๐ฅ Introducing breaking changes. - (:boom:)
// ...changes
๐ Updating the UI and style files. - (:lipstick:)
๐ฑ Adding or updating assets. - (:bento:)
๐ฅ Removing code or files. - (:fire:)
๐ Moving or renaming files. - (:truck:)
// ...reliability
๐ง Changing configuration files. - (:wrench:)
โ Adding a dependency. - (:heavy_plus_sign:)
โฌ Upgrading dependencies. - (:arrow_up:)
โ Removing a dependency. - (:heavy_minus_sign:)
โฌ Downgrading dependencies. - (:arrow_down:)
// ...ideas
๐ฉ Writing bad code that needs to be improved. - (:hankey:)
๐ป Writing code drunkenly. - (:beers:)
// =============================================================================
// Refine...
// =============================================================================
// ...flaws
๐ Fixing a bug. - (:bug:)
โ Fixing typos. - (:pencil2:)
โ
Adding tests. - (:white_check_mark:)
๐จ Removing linter warnings. - (:rotating_light:)
๐ก Documenting source code. - (:bulb:)
// ...quality
๐จ Improving structure / format of the code. - (:art:)
๐ Updating code due to code review changes. - (:ok_hand:)
๐ฝ Updating code due to external API changes. - (:alien:)
โก Improving performance. - (:zap:)
๐จ Refactoring code. - (:hammer:)
๐ฆ Updating compiled files or packages. - (:package:)
// ...stability
๐ Critical hotfix. - (:ambulance:)
๐ Fixing security issues. - (:lock:) // "Addressing" instead of "Fixing"
๐ Addressing iOS. - (:green_apple:) // "Addressing" instead of "Fixing"
๐ค Addressing Android. - (:robot:)) // "Addressing" instead of "Fixing"
๐ธ Addressing Web and Browser. - (:web:) // Non-Standard Gitmoji
๐ฐ Addressing Server. - (:satellite:) // Non-Standard Gitmoji
๐ Fixing something on macOS. - (:apple:)
๐ง Fixing something on Linux. - (:penguin:)
๐ Fixing something on Windows. - (:checkered_flag:)
I am not 100% sure about the categories, but it should probably not be more than 3. This list feels, due to categorization and sorting more approachable for usual workflows (though probably not perfect) because โ in many cases โ emojis can simply be chained top to down.
I.e. fixing a bug on ios: ๐๐ฆ ๐
-> "Fixing bug by re-compiling libraries for xcode."
We work with react-native and web. We are going to create promotion material that will incorporate gitmoji as swag / print out cards.
We'll likely go with this but I want to gather feedback to see what could be improved.
Best
Dino

Hey @D1no
I don't think we really need a categorization for Gitmojis, I think it's better to keep it simple!
Hey @carloscuesta, ok that is fair. My goal is to formalize the emoji use as a tag system that aligns with common workflows.
Since we use many emojis as CI triggers of certain kinds, we decided to build a development framework around our use of emojis. The full spec will release on August 23. at my talk on React Native Continues Integration Strategies in Berlin. I designed a cheat-sheet following the principle, that โ though not officially released โ can anyone download here:
Simply Print and Fold (you don't need staples โ just stick the ends into each other).

gitmoji-triangle-A4.pdf
gitmoji-triangle-US-Letter.pdf
This can also be used as a general github cheat sheet.
Best
Dino
Looks cool! Though I think that the paper format it's not really usable, as long as it becomes outdated really quickly
I don't think categories are necessary and your idea differs a little bit from gitmoji but I love to see things built with gitmoji ๐ ๐
Well as a framework, there should be hardly any breaking changes. And if so, one maybe has to run
lp -d pullprint gitmoji-triangle-A4.pdf to get up to date ๐
Cheers & nice Sunday!
Most helpful comment
Hey @carloscuesta, ok that is fair. My goal is to formalize the emoji use as a tag system that aligns with common workflows.
Since we use many emojis as CI triggers of certain kinds, we decided to build a development framework around our use of emojis. The full spec will release on August 23. at my talk on React Native Continues Integration Strategies in Berlin. I designed a cheat-sheet following the principle, that โ though not officially released โ can anyone download here:
Simply Print and Fold (you don't need staples โ just stick the ends into each other).

gitmoji-triangle-A4.pdf
gitmoji-triangle-US-Letter.pdf
This can also be used as a general github cheat sheet.
Best
Dino