/images/git-logo.png

TLDR: How to setup husky and enforce some convention in your commits, and how we added the Jira Ticket number to the message as well.

What?

Setting up husky and commitlint, to enforce convention based commits.

Why why why?

So that we can autogenerate the change log.

The end result will be:

  • Developers will only be-able to commit messages that conform to the standard
  • A default template will be auto-generated with the Jira ticket in the footer

Installation and setup

We are going to setup husky and commitlint to enforce convention-based commits as described here:

https://github.com/typicode/husky

https://www.conventionalcommits.org/en/v1.0.0/

https://github.com/conventional-changelog/commitlint

https://github.com/conventional-changelog/standard-version

Standard Version

This is the tool that will auto create the change log and bump our version number.

Now the magic, change log creation

Auto generated message

Yeah, so I'm lazy, and I want the jira ticket number in the footer, so an easy way to do that would be? Well just get it from the branch name! You did create a branch right? That included the ticket number right?

Mostly we only use feat, that is just the way it is.

#Hint: feat, chore, docs

Refs : SDEL-9090-The-name-on-the-ticket

This will only work for those who are using an editor to write the git messages, the command line version alas will not help.

Git workflow and in practice

We are working on ticket from Jira, the first thing we all should be doing is? Creating a branch.

All of our branches are checked out from the develop branch, easy right.

# [type-of-change]/[JiraRef-Ticket-Title]
git checkout -b feature/SDEL-12345-Person-Trace-Home-Page

git checkout -b fix/SDEL-12345-Person-Trace-Home-Page

git checkout -b chore/SDEL-12345-Person-Trace-Home-Page

git checkout -b docs/SDEL-12345-Person-Trace-Home-Page

feat , fix, docs, style, refactor, perf, test, build, ci, chore, revet

Squash Commits for a better git history

When working on a feature you may find that you are doing lots of small commits, this really is how you should be working. You can thing of a commit as a safe point, that you can revert to. You may not want to push these commit to the remove repository, but if you do not worries.

Now then, when your feature is ready, you want to squash all those commits into one commit message. You can thing of this as a clean up, this is the moment you write a good full commit message, listing what you change what you did and perhaps why.

Rebase with develop

Now this is the part where you want to update your local branch with develop, we want our changes to be on the top of the change log ( that's how I think about it ).

Make sure you have the latest version of develop.

git rebase -i develop