Conventional commits are just a set of rules that make the versioning of a github project much easier than traditional commits. It is very easy to implement conventional commit.

But before going into conventional commit lets look into Semantic versioning. ####Semantic Versioning (SemVer): Semantic versioning is just a type of versioning that are mostly followed in many projects and it gives meaning to the versions. Semantic versioning has three components as

X.Y.Z

• X - represents MAJOR breaking changes
• Y - represents MINOR changes that affect the behaviour for the customers.
• Z - represents PATCH releases that has bug fixes and some other changes that doesn't affect behaviours.

As an example see the versions of react js here.

###Conventional Commits:

The steps to be followed for normal github commit can be seen here.

The basic git commit will have a message, in conventional commit this message will have a specific format . The structure for Conventional commit message will be

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Type:

The type says about the type of changes that have been made in this version. Mostly used type will be

• feat: Add new feature to the codebase.
• fix: Fix a bug.
• test: Add test to an existing feature.

The other types will be docs, refactor, perf and chore.

Scope:

• It represents the area that the changes have been made.
• If breaking change occurs, an ! can be placed at the end of the scope.

Description:

• Brief statement describing the changes.
• Gitmojis can be used at the start of the descriptions.

Body:

• If the release requires a longer description this body can be used.
• BREAKING CHANGE can be introduced either in body or footer.

Footer:

• Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value.

####Example

1. With type and description

feat: Add support for DevTools

2. With optional scope

feat(lambda-article): add new article on lambda functions

3. With BREAKING CHANGE as footer

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

4. With Multiple footers:

fix: correct minor typos in code
Reviewed-by: Z
Refs #133

#####Relation with Conventional commit and SemVer:

1. fix type will relate to PATCH release in Semantic Versioning.
2. feat type will relate to MINOR release.
3. BREAKING CHANGE will relate to MAJOR release, regardless of type.

Main Benefit:

• Can make automatic CHANGELOG files.
• Easy to understand changes by reading commit message.