When working with Git, writing clear and concise commit messages is essential for effective collaboration and maintainability of code. One approach to improve the quality of Git commit messages is to use Semantic Commits.

Semantic Commits are a convention for writing commit messages that provides a structured and consistent format. It should contains a type, a scope, and a subject, all separated by colons.

In each of these examples, the header follows the format of :

ℹ️ type(scope): subject <optional metadata>

The type describes the nature of the change (such as adding a new feature or fixing a bug), the scope indicates the part of the codebase that was modified, the subject provides a brief summary of the changes in the imperative mode, and the metadata which is optional can provide context and additional details about the changes, such as the issue number or the author of the changes. These commit messages are clear and descriptive, making it easier to understand the nature of the changes and why they were made.

The type

What types I use at my daily work:

• feat: A new feature or enhancement to existing functionality. For example, "feat(user): Add ability to reset password."
• fix: A bug fix or correction to existing functionality. For example, "fix(login): Fix issue preventing users from logging in."
• refactor: Changes to the codebase that do not add new features or fix bugs, but improve the structure, readability, or maintainability of the code. For example, "refactor(payment): Simplify payment processing code."
• style: Changes to the formatting, style, or code layout that do not affect the functionality of the code. For example, "style(user): Format user profile page."
• test: Adding or modifying tests for existing functionality. For example, "test(cart): Add test for cart checkout process."
• docs: Changes to documentation, such as updating README files or inline code comments. For example, "docs(auth): Update authentication documentation."
• chore: Changes to the build process, dependencies, or other maintenance tasks that do not affect the functionality of the code. For example, "chore(deps): Update dependency versions."

The scope

The scope is optional and can be used to indicate which part of the codebase was modified. For example, if you modified the login functionality, you could use "auth" as the scope.

The subject

The subject is a brief summary of the changes, written in the imperative mode. This means that the subject should start with a verb in the present tense, and it should describe what the commit does, not what it did. For example, instead of writing "Fixed login bug," you should write "Fix login bug." This makes the commit message more actionable and easier to understand. When I write commit message I have a hint when I compose commit message - "If I apply that commit, it will {your commit message which you are going to commit}".

✍️ Use the imperative mood in commit

Here's an example of a Semantic Commit message:

• feat(auth): Add support for social media login (#32124)
• fix(cart): Fix issue with cart calculation (#28567)
• refactor(user): Refactor user registration code (#29745)
• style(product): Format product detail page (#29812)
• test(login): Add test for login form validation (#29015)
• docs(readme): Update README with installation instructions
• chore(deps): Update package dependencies (#30867)

The metadata

This information can help provide context and additional details about the changes being made. At my company where I work SoftFormance we use Redmine project management tool and we work by tickets. I always add ticket number in metadata. Also, if the changes being made are not backward-compatible with existing code, including a note about this can help alert other developers to potential issues that may arise when updating their code.

While Semantic Commits provide a structured and clear way to write Git commit messages, you can also add some personality and fun to your commits by using emoji.

Using emoji in Git commits can help convey emotions, add humor, or simply make your commit messages more interesting. Some developers use specific emoji to denote the type of change being made, while others use them as a way to add a personal touch to their commits.

For example, you might use the following emoji to represent different types of changes:

• 🎉 : For adding a new feature or functionality
• 🐛 : For fixing a bug
• 🔨 : For making code improvements or refactoring
• 💄 : For making cosmetic changes such as updating the UI or formatting code

You can also use other emoji to add humor or personality to your commits, such as 🚀 for making performance improvements, 🤓 for adding technical documentation, or 🐢 for slow performance issues.

When using emoji in Git commits, it's important to remember to use them in moderation and to keep them professional and appropriate for the context. Additionally, not all Git clients support emoji, so be aware that they may not display correctly in all instances.

Overall, using emoji in Git commits can be a fun and creative way to add some personality to your commit messages, while still following the best practices of Semantic Commits.

Writing Semantic Commits can help in debugging and collaboration with other developers in the future. When working on a project, having clear and descriptive commit messages can save valuable time and effort in identifying and fixing issues. Additionally, it can make it easier for other developers to understand the changes made to a codebase, which can lead to more effective collaboration and communication.

While it may take some effort to establish the habit of writing Semantic Commits, the long-term benefits make it well worth the investment. Many open-source projects on GitHub require the use of Semantic Commits, making it an important skill for developers to learn if they plan on contributing to these projects or working collaboratively with other developers. By making Semantic Commits a habit, developers can improve the quality of their Git commit messages and make it easier to understand and maintain their code over time.