When a developer goes back in time to look for something he has worked on six months ago, many times he does not understand why he made that particular commit, and the only reason for that is because he didn’t follow the correct way to write the commit message. There are commit message standards that devs practice around the world, and it is good to follow popular standards so that when you come back after a good amount of time or someone else looks at your commit messages, they would not look like cringe! The most effective technique to inform other developers of the context of a change is with a well-written Git commit message. The most effective technique to inform other developers of the context of a change is with a well-written Git commit message. Teams should first decide on a commit message convention that specifies the version control history of the product they are building. A great Git commit message should have a proper style, content, and metadata. A known Git commit follows this convention: <type>(<scope>): <message> <type>(<scope>): <message> <type> can be one of the following: <type> feat for a new feature. refactor for refactoring production code, e.g., renaming a function. docs for changes to the documentation. fix for a bug fix for the user. perf for performance improvements. style for formatting changes, missing semicolons, etc. test for adding missing tests, refactoring tests. build for updating build configuration, development tools, or other changes irrelevant to the user. feat for a new feature. feat refactor for refactoring production code, e.g., renaming a function. refactor docs for changes to the documentation. docs fix for a bug fix for the user. fix perf for performance improvements. perf style for formatting changes, missing semicolons, etc. style test for adding missing tests, refactoring tests. test build for updating build configuration, development tools, or other changes irrelevant to the user. build You can also add your custom type, too, depending on the standards your team follows. The above standards are followed by the ESLint team. You can check their commit messages here. here The scope is optional, and the message part should include a single line statement, no more than 72 characters, to sum up what the commit is for. Many developers also use the message as the subject line and add a body too; that is basically the description of the commit, but a one-liner commit message is preferable as long as you can understand the context (commit what's and why's). If the commit demands a more detailed description that can not be explained in a single line, a commit body is always necessary. You can also use tools like Glitter or Commitizen to standardize your commit messages. Glitter Commitizen Not only this, you might also wonder if there is a tool that checks for your commit message and pops an error if it does not follow the guidelines. Commit lint is one of them. It helps your team adhere to a commit convention. Commit lint Many times, industry experts use their JIRA or Click Up ticket as the commit message so that everything can be linked or traced back anytime, and the codebase remains maintainable for future developers. Some teams also like to add emojis to their commit messages. I have curated a list of emojis and their respective meanings. You can check it out here. here At the end, the important thing is that your commit message should be meaningful and does not confuse your fellow developers or future developers about what a particular change is about. If you wish to learn more about conventional commits, semantic commits, or the practices that the industry follows, here are some resources for you: Conventional Commits Semantic Commits How to write a commit message by CBeams Conventional Commits Conventional Commits Semantic Commits Semantic Commits How to write a commit message by CBeams How to write a commit message by CBeams
