DEV Community

Cover image for Enhance your git log with conventional commits

Enhance your git log with conventional commits

Maxence Poutord on March 11, 2019

Git is a very powerful tool installed on most of our machines. As developer, we use it every day. But, unfortunately, at first glance, this tool is...
Collapse
 
joelnet profile image
JavaScript Joel

I have added husky + commitizen + commitlint to our projects and it has been great.

Some benefits include an auto-generated change log. auto-incrementing semantic versioning. and increased visibility for breaking changes.

I would recommend it for every project.

Because we are using gitlab, we are using these packages semantic-release-gitlab and npm-publish-git-tag.

Collapse
 
maxpou profile image
Maxence Poutord

woaw those 2 libraries looks great! Thanks for sharing!

Collapse
 
eidsonator profile image
Todd Eidson

Wow! Thank you for this. Got it up and running yesterday, I'm loving it.

Collapse
 
brandonkal profile image
Brandon Kalinowski • Edited

I've used Conventional Commits before but am not a fan of the prefix approach. It often seems arbitrary and makes a git log --oneline less readable. We can accomplish the same with imperative mood english, just as git itself does.

For instance, rather than writing:

feat(template): add a favorite color option

You could instead write:

Add favorite color option for template

You could even remove the scope part as if your project is well organized the changed file should convey this same information.

This is human parseable and machine parseable. We both understand that a subject that starts with "Add" is a feature. You can extend that with regex validation for the other types. The subject can be directly copied into a changelog without stripping prefixes

Examples of git's own messages:

Revert "x"
Merge "x"

chris.beams.io/posts/git-commit/

Collapse
 
maxpou profile image
Maxence Poutord • Edited

We both understand that a subject that starts with "Add" is a feature

Depends. This is not standardised. You may not have the same understanding of your colleague

About the scope, I agree. In small project, it's not necessary. THat's why this field is optional btw.

Collapse
 
brandonkal profile image
Brandon Kalinowski

By "we" I meant machine and human. To ensure complete understanding among peers I agree a simple spec (which would likely be an extension of conventional commit) is in order. Even among the "example" repositories for conventional commit many commits do not follow the spec (i.e. Merge ...). Among other projects such as Deno, I see some commits by maintainers that do not follow the prefix approach as it is more clear without it.

Almost every feat commit I see in the wild starts out as "feat: add" so the prefix is redundant for machines here and a changelog generator should work with or without the prefix.

Even among my monorepos I found scope annoying though I added it habitually it doesn't really add to clarity much. So I'm glad it is optional.

Collapse
 
joycebabu profile image
Joyce Babu

I am trying to use the semantic commit messages, but find it difficult to categorize some commits. What type would you on changing a configuration variable, say the password for a database?

Collapse
 
maxpou profile image
Maxence Poutord

hey Joyce.
I'm now using semantic commit messages with semantic release.

  • fix: I'm fixing a bug. Patch release
  • feat: I'm adding a feature. Minor release.
  • whatever+BREAKING CHANGE. I'm breaking compatibility. Major release.
  • chore: everything that does not impact the user of my app/website.

If you're changing the password in a db, I'd use the chore keyword.
After feel free to add/remove keywords. For instance, in my blog, I added the post keyword for everything related to blogposts!

I hope it helps you :)

Collapse
 
joycebabu profile image
Joyce Babu • Edited

Thank you for your response.

I am using this for an internal project (web application), so the concepts of release and breaking changes does not apply in my case. I am using chore as of now.

Some projects restrict chore type to commits that does not cause a production code change.

Collapse
 
loki profile image
Loki Le DEV

This is a good idea, also you can provide git hooks (client side or even better server side) to validate the formatting of the message and automatically reject commits that don't follow this rule.

Collapse
 
maniflames profile image
Maniflames

I'm a really big fan of conventional commits! Haven't seen the perf: before but I like it a lot. Thanks for the nice article 😄

Collapse
 
maxpou profile image
Maxence Poutord

thank you!
About the perf it's up to you. Feel free to add/remove keywords according to your project. For instance, in my personal blog I added the post keyword when I add a blogpost!

Collapse
 
thesanjeevsharma profile image
Sanjeev Sharma • Edited

Hey! Nice post.

What do I write in the commit message if it's a CSS update. chore(css): updated btn-theme?

Collapse
 
maxpou profile image
Maxence Poutord

Hey Sanjeev! Thank you!

Well it depends!
Is this color change a:

  • bug fix? ie. an oversight from a previous commit...
  • a feature? ie. you added a new theme in your website...
  • a refactor? ie. you decided change the css classes...