# How to write good commit messages

If you are here, chances are you have already used git and probably thinking "Am I writing my commit messages in a good standard?".

If yes, then you must read this before you go and do your next big project.

So what is a good commit message?

Well, there's actually multiple standards when it comes to git commit messages. But they all should,

1. Be written in imperative mood if it is a simple commit (means a one liner).
2. Have a title in imperative mood if it is a detailed commit.
3. Write logically, each addressing a single concern.
4. Reference issues or tasks explicitly (if there is any).

Let's look at an example

Simple Commit:

Fix typo in README

Detailed Commit:

Add caching mechanism to improve performance

Implemented a caching layer to reduce redundant database calls,
which improves page load times by approximately 30%.

Fixes #42.

This is written following the Git flow style commits standard.

So what are the other standards then?

Since there's many, I won't be writing all of them here. Below standards will be the ones you'll most probably should be using and encounter as a software developer. Some further references will be linked at the end of the article for curious people.

1. GitHub Flow-Style Commits:

Popular for open-source projects in GitHub. Often references related issues or pull requests (e.g., "Closes #123").

Add pagination to the blog list view

Pagination improves performance for blogs with a large number 
of posts. Closes #42.

2. Conventional commits:

Probably the most widely used standard. Have a type at the beginning followed by a semi-colon and then a scope, description, body and a footer.

The commonly used types are,

• feat: A new feature.
• fix: A bug fix.
• docs: Documentation updates.
• style: Code style changes (e.g., formatting, no logic changes).
• refactor: Code restructuring without changing behavior.
• perf: Performance improvements.
• test: Adding or updating tests.
• build: Changes to build tools or dependencies.
• ci: Continuous integration updates.
• chore: Miscellaneous tasks (e.g., updating dependencies).
• revert: Reverts a previous commit.

Scope (Optional):

The part of the codebase affected (e.g., auth, api, ui).

Description:

A short summary of the change in the imperative mood.

Body - for detailed commits(optional):

Detailed explanation of the change.

Footer - for detailed commits(optional):

Breaking changes (BREAKING CHANGE: ...) or issue references (Fixes #123).

2. Tim Pope's Guidelines:

Tim Pope, a Git expert, suggests:

• Limit subject line to 50 characters.
• Capitalize the first word of the subject.
• Do not end the subject with a period.
• Use the imperative mood.
• Separate the body with a blank line.

Refactor user authentication module

Simplified the code by removing redundant checks and aligning
with the latest OAuth2 library changes.

3. Angular Commit Guidelines:

The foundation for Conventional Commits.
Adds a specific format with types, scopes, and more.

feat(user): add user profile page

This page includes basic details about the user and their recent
activity. Also adds lazy loading for the profile module.

4. Semantic Commit Messages:

Focuses on using keywords to make commits machine-readable.
Often integrated with tools like semantic-release.
Similar to Conventional Commits but may include specific metadata.

feature(login): implement Google OAuth login

6. Subject-Prefix Standards:

Uses a prefix to indicate the change type.
Less formal than Conventional Commits.

[Bugfix] Resolve incorrect total calculation
[Enhancement] Improve search performance

For further references

• Conventional Commits - https://www.conventionalcommits.org/en/v1.0.0/
• Tim Pope's blog post on commit messages - https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
• Senamtic Versioning - https://semver.org/
• Angular git commit guideline - https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit

Thank You

Load of thanks for reading up to here. comments are welcome. Point out if I have missed any details or stated anything erroneously. Let's learn together and grow to become better developers.