How to format the Code Commit Message?
2 min readNov 7, 2022
Is there any standard to format my commit message?
Conventional Commits:
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of.
The commit message should be structured as follows:<type>[optional scope]: <description>
The commit type can include the following:
feat– a new feature is introduced with the changesfix– a bug fix has occurredchore– changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies)refactor– refactored code that neither fixes a bug nor adds a featuredocs– updates to documentation such as a the README or other markdown filesstyle– changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.test– including new or correcting previous testsperf– performance improvementsci– continuous integration relatedbuild– changes that affect the build system or external dependenciesrevert– reverts a previous commit
Examples:
1) feat: allow provided config object to extend other configs2) Commit message with ! to draw attention to breaking change
feat!: send an email to the customer when a product is shipped3) Commit message with scope
feat(api)!: send an email to the customer when a product is shipped4) chore!: drop support for Node 65) chore: Bumped version of axios6) docs: correct spelling in Readme.md
Why Use Conventional Commits
- Automatically generating CHANGELOGs.
- Automatically determining a semantic version bump (based on the types of commits landed).
- Communicating the nature of changes to teammates, the public, and other stakeholders.
- Triggering build and publish processes.
- Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
