Alternative Git Conventional Commit Style: My Personal Approach to Better Code Management

When working with Git, it’s important to have a clear and consistent way of communicating changes to your codebase. The conventional commit style is a widely used standard for writing commit messages that helps keep track of changes and makes it easier to understand what’s been done. However, I found that the conventional commit style didn’t always fit my needs, so I came up with my own set of commit message prefixes that better reflect the types of changes I make most frequently.

Here are the prefixes I use in my alternative Git conventional commit style:

• ✨ ~ New feature (feat) [sparkle]
• 🐛 ~ Bug fix (fix) [bug]
• 🚑 ~ Critical bug fix [ambulance]
• 👷 ~ Changes that affect the build system or external dependencies (build) [construction_worker]
• 📦 ~ Update task runners and dependencies (chore) [package]
• 💚 ~ Changes to CI configuration files and scripts (ci) [green_heart]
• 📝 ~ Documentation only changes (docs) [memo]
• 💄 ~ Changes that do not affect the meaning of the code (white spaces, formatting, semi-colons) (style) [lipstick]
• 🧹 ~ A code change that neither fixes or bug nor adds new feature (refactor) [broom]
• ⚡ ~ A code change that improves performance (perf) [zap]
• 🧪 ~ Add missing tests or correcting existing once (test) [test_tube]
• ❌ ~ Reverting changes with associated git hash (revert) [x]
• 🚀 ~ Deploy stuff [rocket]
• 🚧 ~ Work in progress [construction]
• 🔖 ~ Release/version tags [bookmark]
• 🌐 ~ Add localization and internalizations [globe_with_meridians]

Let’s look at each of these in more detail:

✨ New feature (feat)

Use this prefix when you add a new feature or functionality to your codebase. This could be a new UI component, a new API endpoint, or anything else that adds new capabilities to your application.

🐛 Bug fix (fix)

Use this prefix when you fix a bug or error in your codebase. This could be a syntax error, a logic bug, or any other issue that prevents your code from working as expected.

👷 Changes that affect the build system or external dependencies (build)

Use this prefix when you make changes to your build system, like updating your package manager or changing your build scripts. This could also include changes to external dependencies like adding a new library or upgrading an existing one.

📦 Update task runners and dependencies (chore)

Use this prefix when you make changes to task runners or other development tools. This could include updating your testing framework, optimizing your build process, or making other changes that improve your development workflow.

💚 Changes to CI configuration files and scripts (ci)

Use this prefix when you make changes to your CI configuration files or scripts. This could include changes to your build pipeline, your testing configuration, or any other changes that affect your continuous integration setup.

📝 Documentation only changes (docs)

Use this prefix when you make changes to your documentation files, like updating your README or adding new documentation to your codebase.

💄 Changes that do not affect the meaning of the code (white spaces, formatting, semi-colons) (style)

Use this prefix when you make changes to your code that don’t affect its meaning. This could include changes to formatting, whitespace, or other stylistic changes.

🧹 A code change that neither fixes or bug nor adds new feature (refactor)

Use this prefix when you make changes to your code that don’t fit into any other category. This could include refactoring code for performance or readability or making other changes that improve your codebase without adding new features or fixing bugs.

⚡ A code change that improves performance (perf)

Use this prefix when you make changes to your code that improve its performance. This could include optimizing algorithms, improving memory usage or making other changes that make your code run faster or more efficiently.

🧪 Add missing tests or correcting existing once (test)

Use this prefix when you add new tests to your codebase or correct existing ones. This could include adding unit tests, integration tests, or any other tests that help ensure the quality and correctness of your code.

❌ Reverting changes with associated git hash (revert)

Use this prefix when you need to revert to a previous commit. This could be necessary if you accidentally introduced a bug, or if a feature you added caused unexpected issues.

Summary

By using these prefixes consistently in your commit messages, you can make it easier for yourself and others to understand what changes have been made to your codebase. Additionally, using clear and descriptive commit messages can help you maintain a clean and organized Git history, making it easier to track changes over time.

Of course, these prefixes are just a starting point. You can always customize them to better fit your needs or add new ones, as necessary. The most important thing is to find a convention that works for you and stick with it consistently across your team and projects.

It’s worth noting that the prefixes listed here are intended for use with single scope commits, where each commit is focused on a single change or feature. For larger changes that involve multiple commits, you may need to use a different convention or modify these prefixes to better fit your workflow.

In general, it’s best to keep each commit as small and focused as possible, so that it’s easier to understand and review the changes. This can also make it easier to roll back changes, if necessary, since you’ll have a clearer picture of which commits introduced which changes.

Happy coding!