Skip to content

How conventional commits improved my git skills

Maniflames on January 06, 2019

At the moment of writing this I’m in the final month of my internship. I am slowly realising how much I have learned in the past few months. But of... [Read Full]
markdown guide

Hi Imani, thanks for your post! Didn't know there was a spec about git commits and it's very interesting! It really makes sense since we tend to be "conservative" about explaining commits usually.

In addition you might want to setup a template (basically put the template you explained up there in a template file :D) for your Git commit messages, so that it can help you and the people you collaborate with, with something like:

git config --global commit.template ~/.git-commit-template

Another feature I did not know about! This one will be very useful, thanks for sharing ✨


I've used GiT for over a decade and did not know about this. TYVM @rhymes and @Imani.


Great post about conventional commits Imani! We've been doing it for a year now at Peakfijn (a company I work for), and I never want to go back. We've had some discussions within the team about the types we need and eventually, we created our own type-list based on Angular conventions.

Our biggest problem was to get everyone committing valid commits. Along the way, we found some great tools which can really help. Especially when combining this in an automated continuous integration system! Hope it can help anyone :)

  1. conventional-changelog - Generate changelogs and release notes from a project's commit messages and metadata.
  2. semantic-release - Fully automated version management and package publishing
  3. commitlint - Lint commit messages

Disclaimer; I became one of the maintainers of Commitlint and wrote an Expo plugin for Semantic Release


I'd also add commitizen to that list. It walks you through the steps, at commit, to get the message correct without having to memorise the syntax.

Really great when used in combination with the above tools.


These are some gems! I'll definitely try them out in my upcoming projects :D


Also check out It discusses how to take a lot of smaller commits (which is a good practice of course) and use git rebase to make a single, well documented commit to push.


I'll definitely check it out, seems like that one thing I'm still missing in my current flow


git -a -m "message" can be shortened to git -am "message" btw 😊


Note: only on *nix. Command flag compounding doesn't work under windows.


I think active voice would make it even better, eg:

git commit -m "feat(ratings): Can add star ratings to posts

Multiple users requested this feature.
Note that it changes the database structure.

closes #105"

There are also more fun ways using emojis for commit categories. Have a look at these projects:

But the development team should be not too serious in their ways of working if you choose these.


I am guilty of using emoji's in my commit messages when I'm building small homework assignments I had no idea people have created 'specs' for this πŸ˜‚


I've fallen into the trap of trying to follow conventional commits only to forget or make a typo which will get pushed. So I made Sailr [1] which is an installable Git hook to help you follow the standard. It's flexible and configurable so you can adapt it to your own implementation.

[1] -


"When using conventional commits I can't just collect all the changes I have made in a single commit."

I use to do this. Make a lot of changes in many files and dump them in a single commit. Now I commit small and often. But since the commits are small, I try to use as few words as possible, for the commit message. This results in non-descriptive commit messages.

I have to spend a bit more of my time on writing better, descriptive commit.

Thanks for your post.


Messages are really a pain at times, I really hope this helps 😊


Definitely a good thing. And something I've had a hard time getting people to adopt. I tend to prefer the structure of what was done, breaking changes, how it was tested.

The task assignment is primarily to associate it to the work tracking system in most cases. Jira also has smart commits where you can use a commit message to track time, add details, progress state, etc.

I will say though, most of the line 1 data should be in the commit body. Descriptions on git should be no longer than 50 characters by convention.


Hi Imani, thanks for sharing your experience with us! When I started using git, I was the same way when creating my commit messages.

I did mostly to save progress or bundle all the changes to have one commit. After getting more involved in the dev community and discovering resources. I was able to discover The seven rules of a great Git commit message. This convention has similar rules to your specs. If you really want to enforce these rules, you can create a template as well as git hook so it won't let you commit unless it meets the criteria you set.


Add partial file Commits to your tools if you haven't already.

I've started pushing to bring this conversational commit to my work.

code of conduct - report abuse