Original Link: https://potatoblogger.hashnode.dev/commit-like-a-pro?source=personalized-newsletter&source-id=2023-04-21  Sulagna Ghosh's photo [Sulagna Ghosh](https://hashnode.com/@sulagnaghosh) · 4 min read ## Table of contents - [ Why Use Conventional Commit? ](https://potatoblogger.hashnode.dev/?source=personalized-newsletter&source-id=2023-04-21#heading-why-use-conventional-commit) - [ The conventional way is: ](https://potatoblogger.hashnode.dev/?source=personalized-newsletter&source-id=2023-04-21#heading-the-conventional-way-is) - [ Type of Commits: ](https://potatoblogger.hashnode.dev/?source=personalized-newsletter&source-id=2023-04-21#heading-type-of-commits) - [ Some examples of good commit messages: ](https://potatoblogger.hashnode.dev/?source=personalized-newsletter&source-id=2023-04-21#heading-some-examples-of-good-commit-messages) Remember your first open-source contribution? You typed git commit -m "your commit", pressed enter and suddenly an error showed up with a suggestion link: And all of a sudden your all-git knowledge just crashed and you started thinking "Isn't it the way to commit a message?" Yes, it is the correct way no doubt about that. Still, when you contribute to a project on GitHub or any repository, the maintainers of those repositories expect you to make your commit message more concise, to the point and crisp, which not only helps them to maintain the changelog but also helps you and the other contributors to know precisely what is going on. ## Why Use Conventional Commit? 1. Everyone can easily understand the changes by simply exploring the commit history. 2. Following a rule can make things more systematic and understandable. Otherwise, if everyone starts writing commits without any rule, they can write a paragraph about the changes they have made which will eventually make things messy and may everyone not understand the changes at all. 3. Trigger build and publish processes. 4. Automatically generates [CHANGELOG.md](http://changelog.md/) file. > CHANGELOG is a log or a record of all the changes you made to a project. You can either create a file and save all the record there or you can auto-generate your changelog from the commit messages. > > An easy way create an changelog is: > > `git log --pretty=-%s > CHANGELOG.md` > > where %s means the commit title. ## The conventional way is: > type(scope): description \- type: Commit Type like build, ci, docs, feat, fix etc. \- scope: Phrase describing a section of the codebase. \- description: description should be in the present tense. Not capitalized. No period in the end. Each description consists of a Title, Body and Footer. The Title and Body are mandatory if the description is large enough. The footer is optional. The command is: Example: ```bash git commit -m "docs(guide): change in how to write a professional commit" -m "add rules, specification, example, type" ``` ## Rules & Specification: - A commit must be prefixed with a **type** and an additional scope(which is optional), then a colon after that, then the message describing the changes you made and at the very last a footer. - There must be a space between the colon and the message (this space is mistaken by people commonly and they get errors). ```bash type(scope): description ``` - All words should be lowercase. - No dot (.) at the end of the description. - Use imperative verbs while writing the commit message like add, fix, solve not adding, fixing, solving etc. - Commit must be a brief and clear message that describes what changes you have made. - The **commit title** should not be more than 50 characters, and the **commit body** should be restricted to 72 characters. - Do not use filler words and phrases like though, maybe, kind of etc. - The footer should contain additional issue references, BREAKING CHANGE, and external links about the code changes. ## Type of Commits: - `feat` – use to introduce new features with the changes - `fix` – use to fix a bug or error - `chore` – use when changes that do not relate to a fix or feature, for example updating dependencies etc. - `refactor` – use when performs changes to the code that neither fix a bug nor add a feature such as restructuring the code - `docs` – use when updates the documentation such as a README or other markdown files - `style` – use when changes that do not affect the meaning of the code, which are likely related to code formatting such as white space, missing semi-colons, and so on. - `test` – use when including new or correcting previous tests - `perf` – use for implementing performance improvements - `ci` – use for performing changes, refer to continuous integration or delivery process - `build` – use, for changes that affect the build system or external dependencies - `revert` – reverts to a previous commit ## Some examples of good commit messages: 1. **Commit message with no body or footer** docs: correct spelling in [README.md](http://readme.md/) file 2. **Commit message with a body** style: change page style add change home page style after login 3. **Commit message with a body and footer** fix: solve hover issue see the issue for details fixes issue #999 4. **Commit message with scope** docs(guide/migration): fix spelling mistake ## How a Good Commit History looks like > Git commits history of Angular.js GitHub repository