slurmulon/tasty-commits

:lollipop: Simple commit message convention for easily digestible history streams

tasty-commits

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

Convention

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!

Messages

• 🌱 :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

Combinations

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.

Conflicts

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.

Contributing

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!

Roadmap

• Node API

License

MIT

tasty-commits's Issues

Awesome! :)

Create commitizen configuration

Some people have brought up that it would be nice if you could choose from a list of change semantics during each commit and automatically generate some or all of the emojis.

We might want to handle this in a separate repo, or we can just stuff it into external or configs or something.

https://github.com/commitizen/cz-cli