Writing good commit messages.

Before we start looking at the specific use cases, here’s a quick note about commit messages. Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier.

Good commit messages serve at least three important purposes:

• To speed up the reviewing process.
• To help us write a good release note.
• To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.

DO’s

• Write the summary line and description of what you have done in the imperative mood, that is as if you were commanding someone. Start the line with “Fix”, “Add”, “Change” instead of “Fixed”, “Added”, “Changed”.
• Always leave the second line blank.
• Line break the commit message (to make the commit message readable without having to scroll horizontally in gitk).

DON’Ts

• Don’t end the summary line with a period — it’s a title and titles don’t end with a period.

Tips

• If it seems difficult to summarize what your commit does, it may be because it includes several logical changes or bug fixes, and are better split up into several commits using git add -p.

Explanation of a few Git Messages are as follows:-

• feat — a new feature
• fix — a bug fix
• docs — changes in documentation
• style — everything related to styling
• refactor — code changes that neither fixes a bug or adds a feature
• test — everything related to testing
• chore — updating build tasks, package manager configs, etc