In this tutorial, you will learn about conventional commits, how you can use them to improve your GIT flow and how you can implement conventional commits within your JavaScript-based projects. If the terms convention commits sounds complex and complicated to you, fear not, it is not.
Conventional commits is simply a recommend convention on how a team should write and structure GIT commit messages, that's it. The beauty of having good commit messages will save you time in the future. It will make bug fixing easier, by speeding up the time it takes to find code. In a big project this saving in maintenance time can be really beneficial and a massive time saver. If enforcing something which only takes a few extra seconds per commit to writing that can save time when a live production error occurs, I'm all in 🎰🎰🎰 An example of a conventional commit message could look like this:
As you can see from this example there is nothing too scary, or, complex going on here. The standard is simple to learn and get going with. Next, let us look at the standard in a little more detail!
How To Write Conventional Commit Messages
Writing a conventional commit message is very simple and only takes a few extra seconds. The conventional commit specification defines a commit message to be structured as follows:
Let us break down each part in a little more detail:
- fix: A bug fix
- feat: A new feature
- chore: A refactoring change
I normally set the [optional scope] as the JIRA ticket number. Following this guideline, the beginning of a commit message could look like this:
[optional body] After creating a commit message, we can create an optional body. I tend to skip this bit on most commits:
[optional footer(s)]: The most common thing you will add in the footer (bottom of the commit message) is BREAKING CHANGE. The BREAKING CHANGE comment denotes a MAJOR version bump following SemVar. The package number should be bumped. An example of this syntax:
How To Implement Conventional Commit Messages
When it comes to enforcing the team to use conventional commit messages you will need to apply some GitHooks. Creating GIT hooks and adding them into your GIT Ignore is a chore. Instead, we can use some handy community packages. There are two main packages to start enforcing conventional commit:
I have used both on production-level projects and they both did the job. I had a few issues with CommitZen and NVM so nowadays I tend to stick with CommitLint. CommitLink also works with GIT UI tools like SourceTree. I don't use these type of tools, however, some developers do and it's nice to be inclusive 😊😊😊
