🍭 Simple commit message convention for easily digestible history streams
As a visual person, I find it difficult to read through large commit history logs in binary color schemes (i.e. black / white).
In order to improve readability and understandability of my commit history I started prefixing my messages with emojis in a consistent manner.
Over the years I've made this convention a habit and find it hard to live without, so I figured I'd document the idea to see if others find it useful, too.
Following the message rules described in the following section, simply prefix your commit messages like so:
:EMOJI: my commit message
That's it. Now when you read through your commit history it will be much easier to identify the general flow of your work, which
helps for trackability, recollection, debugging, and fun! 
- 🌱
:seedling:initial commits - ⚓
:anchor:feature scaffolding - 🎨
:art:general feature development - 📺
:tv:user interface or front-end development - 📡
:satellite:API, back-end, or integration development - 💄
:lipstick:styles, colors, sizes, positions, alignment - 🔧
:wrench:configuration, settings, environment variables - 🚧
:construction:work-in-progress, unstable, unusable - 🐛
:bug:bugs, broken windows - 🔥
:fire:error and exception handling - 📼
:vhs:general scripts, task automation, code generation - 🔬
:microscope:test suite additions or updates - 🎭
:performing_arts:stubs, mocks and fixtures - ⚡
:zap:caching - 🚀
:rocket:optimizations - ✨
:sparkles:cleanup, lint, touch-ups - 📦
:package:packages, dependencies - 🏭
:factory:build scripts - ♻️
:recycle:refactoring code - 🚚
:truck:migrating code, data, files or database tables - 🏁
:checkered_flag:large/complex feature checkpoint - 🙈
:see_no_evil:adding technical debt - 💦
:sweat_drops:enigmatic problems - 💥
:boom:removing code, files, or data - 👻
:ghost:temporary or ephemeral changes - 💊
:pill:experimental changes or implementations - 🆗
:ok:conflict resolutions - 💿
:cd:media and static assets - 🔌
:electric_plug:offline mode - 📟
:pager:events, messages, notifications - 🔒
:lock:permissions, authorization, authentication, user sessions - 🔗
:link:routes, paths, links - 👮
:cop:security features, improvements or fixes - 💰
:moneybag:payments, subscriptions, trials, pricing models, financing - 📱
:iphone:media queries, device-specific changes - ☁️
:cloud:networking, deploy, continuous integration - 🎁
:gift:containerization - 👁️
:eye:monitoring, analytics - 📜
:scroll:documentation, wiki, comments, docstrings, general text - 💡
:bulb:assistive content, learning resources - ✉️
:envelope:email templates or content - ❄️
:snowflake:i18n/l10n, partnerification, white labeling - 🔨
:hammer:administration, moderation - 🤠
:cowboy_hat_face:cowboy commit, unreviewed code
Combining emojis can be a great way to either increase message specificity or to support a new type of message that's unique to your own application / workflow.
Here are some common scenarios where combining can be very useful:
:microscope: :bug: fixed a broken test:anchor: :construction: scaffolding work for a critical feature:wrench: :rocket: configuration change that optimizes the application:scroll: :bug: fixed a typo in the documentation:satellite: :package: added a new third-party dependency to the API:tv: :lock: :checkered_flag: finished integrating auth in the client
There are of course an endless number of scenarios where this can be useful, so please feel free to contribute to this list when you find yourself using novel combinations.
One could argue that certain combinations inherently conflict, such as :art: and :bug:, but I believe that context is everything and I want to ensure that no assumptions are made about what contexts users will find themselves in.
So there are no hard and fast rules regarding how you can/should combine emojis. My only suggestion is to be as consistent as possible so that everybody on your engineering team can benefit and pick up the process quickly.
This one is probably as subjective as it gets, but I'm always open to suggestions and objectively discussing which emojis make the most sense. I'm also interested in what other ways commits can be categorized, so please don't be shy!
- Node API
MIT