Introduction

what is a commit message?

A commit in GitHub is described as a saved change. A commit explains what changes you made to the project. It records progress and when you push your code to a remote repository(like GitHub, Bitbucket), these changes show up in remote and could mean any additions, deletions, or updates to the files stored in the repository.

Why are good commit messages important?

If you try to go to any random Git repository, the is a high chances that the commit messages are more or less a mess.

These commit messages are difficult to read and understand the motive behind the commits. Not all commit messages look like this though. If we go and check The Linux kernel and Git , they have some of the best written commit messages. The contributors of these repositories know that a well-written Git commit is the best way to communicate with the fellow developers about the various changes to the program.

• Good commit messages helps to speed up the reviewing process

• It helps to write a good release note

• Helps the future maintainer of the repo to understand why a particular change was made to the code and why a feature was added.

Bad commit create a vicious cycle: as the commit history is unstructured and inconsitent,one doesn't spend much time using or taking care of it. And because it doesn't get enough time, it remains unstructured and inconsistent. A projects long term success depends on its maintainability which depends on maintainer who depends on project's log.

A team should agree on a common convention that defines at least these things:

Style (grammar, punctuations, syntax), Content( information for the body of the message) and Metadata( issuing of tracking ID's, pull request numbers)

Commit Message Format

I am not saying that you have to follow this format to write git messages but having a format helps you to understand the structure of the message and makes it easy to write properly.

It consist of three things: header, body and footer(optional).

Header

It contains the type of build messages which we are going to commit. Some examples of the different types are:

• feat - A new feature
• fix - A bug fix
• docs - Changes in documentation
• style - Style changes, formatting , missing semicolons or whitespaces i.e. everything related to styling
• refactor - code changes that neither fixes a bug or adds a feature
• test - Add missing tests
• chore - changes the build process

Body

Contains a scope(optional) is provided in parentheses after header. It describes the part of code affected by the changes. Subject: The subject contains a short description of the applied changes.

Footer(Optional)

Use to reference issues affected by the code changes. eg "Fixes #20"

eg.

feat(ingredient): add ingredient to list button

style(navbar): add color to active link

In most cases you can leave out the details about how a change has been made as code is self-explanatory in most cases. Just focus on making clear the reasons why the respective change was made and the future contributors and developers(maybe your future self!) will thank you.

Happy coding!