Neovim for Beginners — Conventional Commits

Learn the basics of the Conventional Commits specification and integrate it as part of our development workflow.

5 min readAug 14, 2022

Neovim for Beginners — Conventional Commits

In a previous article, we explore the different plugins related to source code control and learn a few tricks for better source code management.

In this article, we will learn the basics of the Conventional Commits specification, and integrate it as part of our development workflow.

This article is part of the Neovim for Beginners series.

The Neovim configuration files are available in this repository.

Getting Started

Conventional Commits

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Possible values for type — build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test, and others.
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope. It correlates with MAJOR in Semantic Versioning.

Here are the reasons why we use Conventional Commits.

Automatically generating CHANGELOGs.
Automatically determining a semantic version bump (based on the types of commits landed).
Communicating the nature of changes to teammates, the public, and other stakeholders.
Triggering build and publish processes.
Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.