Plan how a new approach to gitmoji could be compatible with strict commit message standards
shrink opened this issue Β· comments
carloscuesta/gitmoji is a fantastic idea that has greatly improved my commit messages but it is somewhat incompatible with strict commit message standards. How can this be improved? This project is intended to explore the options.
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.
How to Write a Git Commit Message
The contributors to these repositories know that a well-crafted Git commit message is the best way to communicate context about a change to fellow developers (and indeed to their future selves).
[...]
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
[...]
5. Use the imperative mood in the subject line
Imperative mood just means βspoken or written as if giving a command or instructionβ. A few examples:Clean your room
Close the door
Take out the trash
Each of the seven rules youβre reading about right now are written in the imperative (βWrap the body at 72 charactersβ, etc.).The imperative can sound a little rude; thatβs why we donβt often use it. But itβs perfect for Git commit subject lines. One reason for this is that Git itself uses the imperative whenever it creates a commit on your behalf.
[...]
A properly formed Git commit subject line should always be able to complete the following sentence: If applied, this commit will
your subject line here
- Squash merge https://blog.dnsimple.com/2019/01/two-years-of-squash-merge/
- Atomic commits https://www.freshconsulting.com/atomic-commits/
gitmoji
Emojis currently included in gitmoji (via carloscuesta/gitmoji-cli@v3.2.10).
Emoji | Shortcode | Description |
---|---|---|
π¨ | :art: |
Improving structure / format of the code |
β‘οΈ | :zap: |
Improving performance |
π₯ | :fire: |
Removing code or files |
π | :bug: |
Fixing a bug |
π | :ambulance: |
Critical hotfix |
β¨ | :sparkles: |
Introducing new features |
π | :pencil: |
Writing docs |
π | :rocket: |
Deploying stuff |
π | :lipstick: |
Updating the UI and style files |
π | :tada: |
Initial commit |
β | :white_check_mark: |
Updating tests |
π | :lock: |
Fixing security issues |
π | :apple: |
Fixing something on macOS |
π§ | :penguin: |
Fixing something on Linux |
π | :checkered_flag: |
Fixing something on Windows |
π€ | :robot: |
Fixing something on Android |
π | :green_apple: |
Fixing something on iOS |
π | :bookmark: |
Releasing / Version tags |
π¨ | :rotating_light: |
Removing linter warnings |
π§ | :construction: |
Work in progress |
π | :green_heart: |
Fixing CI Build |
β¬οΈ | :arrow_down: |
Downgrading dependencies |
β¬οΈ | :arrow_up: |
Upgrading dependencies |
π | :pushpin: |
Pinning dependencies to specific versions |
π· | :construction_worker: |
Adding CI build system |
π | :chart_with_upwards_trend: |
Adding analytics or tracking code |
β»οΈ | :recycle: |
Refactoring code |
π³ | :whale: |
Work about Docker |
β | :heavy_plus_sign: |
Adding a dependency |
β | :heavy_minus_sign: |
Removing a dependency |
π§ | :wrench: |
Changing configuration files |
π | :globe_with_meridians: |
Internationalization and localization |
βοΈ | :pencil2: |
Fixing typos |
π© | :poop: |
Writing bad code that needs to be improved |
βͺ | :rewind: |
Reverting changes |
π | :twisted_rightwards_arrows: |
Merging branches |
π¦ | :package: |
Updating compiled files or packages |
π½ | :alien: |
Updating code due to external API changes |
π | :truck: |
Moving or renaming files |
π | :page_facing_up: |
Adding or updating license |
π₯ | :boom: |
Introducing breaking changes |
π± | :bento: |
Adding or updating assets |
π | :ok_hand: |
Updating code due to code review changes |
βΏοΈ | :wheelchair: |
Improving accessibility |
π‘ | :bulb: |
Documenting source code |
π» | :beers: |
Writing code drunkenly |
π¬ | :speech_balloon: |
Updating text and literals |
π | :card_file_box: |
Performing database related changes |
π | :loud_sound: |
Adding logs |
π | :mute: |
Removing logs |
π₯ | :busts_in_silhouette: |
Adding contributor(s) |
πΈ | :children_crossing: |
Improving user experience / usability |
π | :building_construction: |
Making architectural changes |
π± | :iphone: |
Working on responsive design |
π€‘ | :clown_face: |
Mocking things |
π₯ | :egg: |
Adding an easter egg |
π | :see_no_evil: |
Adding or updating a .gitignore file |
πΈ | :camera_flash: |
Adding or updating snapshots |
β | :alembic: |
Experimenting new things |
π | :mag: |
Improving SEO |
βΈοΈ | :wheel_of_dharma: |
Work about Kubernetes |
π·οΈ | :label: |
Adding or updating types (Flow, TypeScript) |
π± | :seedling: |
Adding or updating seed files |
π© | :triangular_flag_on_post: |
Adding, updating, or removing feature flags |
π₯ | :goal_net: |
Catching errors |
π« | :dizzy: |
Adding or updating animations and transitions |
π | :wastebasket: |
Deprecating code that needs to be cleaned up |
Project Types
- Website
- Blog (source)
- API
- Law
- Documentation
- Specification
- Standard
Example Commits
- Allow train_and_eval to stop and resume. google/automl@5ba7223
- Use static map_fn if batch_size is known. google/automl@4d67007
- Fix the visualization bug in tutorial. google/automl@b80c5fe
- remove net when targeting JS google/uuid@a4243a3
- Tidy up caching and test on API 29 android/compose-samples@96221b9
- Updates accompanist to 0.2.0 android/compose-samples@93547c6
- changed facebook claimed username to hackerman sherlock-project/sherlock@dcfa4c7
- Fix parity enodes + peers file smartcontractkit/chainlink@de0d18f
- Add Kyber, Blocksize and DeFiner to feeds ui smartcontractkit/chainlink@dc3fa09
- Removing tiny-dnn from "Who is using.." google/googletest@7b2f00d
- Make EXPECT_THROW and EXPECT_NO_THROW macros more informative google/googletest@0d2830b
Example commits... with commitmojis
- β¨ Allow train_and_eval to stop and resume. google/automl@5ba7223
- β‘ Use static map_fn if batch_size is known. google/automl@4d67007
- π Fix the visualization bug in tutorial. google/automl@b80c5fe
- β‘ remove net when targeting JS google/uuid@a4243a3
- π· Tidy up caching and test on API 29 android/compose-samples@96221b9
- Updates accompanist to 0.2.0 android/compose-samples@93547c6
- π§ changed facebook claimed username to hackerman sherlock-project/sherlock@dcfa4c7
- π Fix parity enodes + peers file smartcontractkit/chainlink@de0d18f
- π§ Add Kyber, Blocksize and DeFiner to feeds ui smartcontractkit/chainlink@dc3fa09
- π§ Removing tiny-dnn from "Who is using.." google/googletest@7b2f00d
- π Make EXPECT_THROW and EXPECT_NO_THROW macros more informative google/googletest@0d2830b
Rules
- Should describe a commit in the context of a repository -- for example "development environment" not "Docker" -- because otherwise the emoji is very ambiguous (regardless of what the project is the emojis used for the types of commit should be consistent)
- A repository may be for a project that is not code (e.g: a document repository)
- or is a project that provides a tool to use for code (e.g: a github action repository)
- or is a project with source-code for an app
- A commitmoji must describe a change to an area of the project -- not specifically remove or add
- Avoid contradicting gitmoji
- Avoid using similar emojis -- each should be distinct in what they represent
- Avoid cultural references or language specific meanings
- A commit should describe the impact on the project not the code
- Less is more, it should be easy to remember all
- Adding new emojis requires a demonstration of why it should be added (go through process for all initial emojis? a PR for each?)
- Different project types
- Example commits
- Vote?
- Swapping the emoji should change the entire meaning of the message
commitmojis
An initial attempt at taking inspiration from gitmoji and simplifying using the above principles.
Type | Emoji | Example Commits |
---|---|---|
Project / Build? | ||
Developer Experience | π· :construction_worker: |
π· Seed test data on database initialisation |
Feature | β¨ :sparkles: |
β¨ Allow user to authenticate with Google |
Formatting | π¨ :art: |
π¨ Replace tabs with spaces in Javascript source files |
Performance | β‘ :zap: |
β‘ Cache result of photo resizing |
Bug | π :bug: |
π Generate cache key with user identifier |
Hotfix | π :ambulance: |
π Replace user avatar with generic icon |
Documentation | π :book: |
π Describe supported colours for template |
Configuration | π§ :wrench: |
π§ Load hostname from environment |
User Interface | π» :computer: |
π» Emphasise selected project filters |
Security | π :lock: |
π Escape HTML entities in post titles |
Refactor | β»οΈ :recycle: |
β»οΈ Simplify parsing logic with regular expression |
Accessibility | πͺ :door: |
πͺ Label registration form inputs |
Continuous Integration | π₯ :traffic_light: |
π₯ Publish releases to GitHub Package Registry |
Publish | π :gift: |
π Release v1.10 |
Localization | π :globe_with_meridians: |
|
Agreement | π :bookmark_tabs: |
π License project under MIT |
Log | π :memo: |
π Include last activity timestamp in user metadata |
People | πͺ :family: |
πͺ List @example as a Gold sponsor |
SEO | π :mag: |
π Mark profile root page as canonical profile page |
Seed | π± :seedling: |
π± Give each registered user a default profile photo |
Deprecation | ποΈ :wastebasket: |
ποΈ Replace structured user name with free display name |
Feature Flag | π© :triangular_flag_on_post: |
π© Enable light mode for all paying users |
Infrastructure | ||
Dependency |
TODO
- Add examples for diff project types: application sourcecode, documents, tool
name: c:ring:mmitmoji (?)
- Review the commits of projects that use gitmoji (e.g: gitmoji itself) and then compare to the proposed commitmojis above, preparing a table showing the difference between gitmoji and commitmoji to give a clearer picture of the impact
Conventional Commits is interesting but I'm not sure it captures the same value, but it does have nice tooling so perhaps there's a way to introduce emojis into that standard in some way as an extension? Semantic versioning is valuable for libraries but not so much projects, do the machine readable benefits of Conventional Commits provide value in projects at the expense of humans? The Angular example is worth digging into because they have a mature project implementing the approach.
- Review Angular usage of Conventional Commits and decide if that is better than emojis
Build of [the thing]
Configuration of [the thing]
Feature of [the thing]
Fixing a bug in [the thing]