(Commit) Message in a bottle

Imagine: You just finished writing the perfect piece of code. Spending hours - probably days - making it shiny and clean. Following all the best practices. Even adding some documentation! And you know. This code is ready to enter the world. You lean back. Ready to commit your code. Ready to commit you code? Oh no... you need a commit message... How to summarize the world changing code you just created? The blinking cursor jeers you. Your head is blank. It feels like the world is waiting for your genius commit message. Your fingers move carefully and slowly across the keyboard. You start typing. Quickly. "new stuff". Commit. Push. And that's it.

Can you relate to that? Than you're probably not alone.

Why good commit messages matter

But well-written and meaningful commit messages can be of advantage. They help you, future-you and other developers to understand what and how you built your project. And they help you to work faster. If you have a consistent structure of commit messages, you can automatically create changelogs or software versions. You could also automatically trigger build and publish processes.

Conventional Commits

Luckily there already is a specification that helps to create better commit messages: Conventional Commits. Sometimes this specification is also referred to as semantic commits.

Structure of Conventional Commits

<type>[optional scope]: <description>



[optional body]



[optional footer(s)]

Example:

feat(auth): add new authentication role



Add role of 'Witch' - a role that magically gets access to every page



Refs: TICKET-1337

Types

The type is mandatory and gives a first hint on what the commit contains. The following types are defined in the Conventional Commit:

• 
  feat - introducing/removing a new feature


• 
  fix - repairing a bug


• 
  build - adding/updating build system or external dependencies


• 
  chore - updating internal code, no production code change (e.g. initial commit, change .gitignore)


• 
  ci - changing CI configuration


• 
  docs - adding/updating documentation


• 
  style - updating the code without changing the meaning (formatting, white-spaces, &c.)


• 
  refactor - refactoring code


• 
  perf - improving performance


• 
  test - adding/updating tests

Sidenote: If you're more the picture-type, you could think about using

Inspired by

• https://dev.to/safdarali/good-commit-vs-your-commit-how-to-write-a-perfect-git-commit-message-59ol