# How to Write Better Git Commit Messages – A Step-by-Step Guide  URL:: https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/ Author:: Natalie Pina ## AI-Generated Summary Writing clear and informative commit messages is important for developers using Git. This guide provides step-by-step instructions on how to write better commit messages. It covers topics such as capitalization and punctuation, using imperative mood, specifying the type of commit, keeping the length of the message concise, and providing clear content. The guide also suggests adopting Conventional Commits, a formatting convention that provides rules for structuring commit messages. Following these guidelines can improve collaboration and communication within engineering teams and make it easier to understand and troubleshoot code changes in the future. ## Highlights > 5 Steps to Write Better Commit Messages > Let's summarize the suggested guidelines: > 1. Capitalization and Punctuation: Capitalize the first word and do not end in punctuation. If using Conventional Commits, remember to use all lowercase. > 2. Mood: Use imperative mood in the subject line. Example – `Add fix for dark mode toggle state`. Imperative mood gives the tone you are giving an order or request. > 3. Type of Commit: Specify the type of commit. It is recommended and can be even more beneficial to have a consistent set of words to describe your changes. Example: Bugfix, Update, Refactor, Bump, and so on. See the section on Conventional Commits below for additional information. > 4. Length: The first line should ideally be no longer than 50 characters, and the body should be restricted to 72 characters. > 5. Content: Be direct, try to eliminate filler words and phrases in these sentences (examples: though, maybe, I think, kind of). Think like a journalist. ([View Highlight](https://read.readwise.io/read/01hpcc6t9h0k5hsda9pycgrr8e)) > The commit type can include the following: > • `feat` – a new feature is introduced with the changes > • `fix` – a bug fix has occurred > • `chore` – 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 feature > • `docs` – updates to documentation such as a the README or other markdown files > • `style` – 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 tests > • `perf` – performance improvements > • `ci` – continuous integration related > • `build` – changes that affect the build system or external dependencies > • `revert` – reverts a previous commit ([View Highlight](https://read.readwise.io/read/01hpcc7nk10b7mph1pj2vxr65q))