J. Making Better Commits with Git Hooks

We are getting there I promise!

Now let's implement 3 packages: commitizen, cz-conventional-changelog, & husky

Yellow-Stone:picnic-basket-generator yogibear$ npm I -D commitizen cz-conventional-changelog husky

In our PJ we are going to add a few scripts & a config object now:

"scripts": {
  "precommit": "run commands here before committing",
  "commit": "git-cz"
},
"config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
}

What does it all mean?

The config is just telling commitizen which adapter we want our contributors to use when they try to commit to the repository.

husky is going to make sure our git hooks are being ran, so when you run:

Yellow-Stone:picnic-basket-generator yogibear$ npm run commit
### npm run precommit will be ran before executing the commit script

So before you commit code you can type-check, lint, test, etc. If you want to learn more about the git hooks available to you go here

Now with commitizen instead of running:

Yellow-Stone:picnic-basket-generator yogibear$ git commit -m "initial commit"
### We will run
Yellow-Stone:picnic-basket-generator yogibear$ npm run commit

What this will do is start up the commitizen CLI that is going to provide us with an easy interface for making meaningful commit message pertaining to our changes and assist semantic-release with the versioning of our package.

You should see something like this:

Yellow-Stone:picnic-basket-generator yogibear$ npm run commit
? Select the type of change that you are committing: (Use arrow keys)
  feat: A new feature
  fix: A bug fix
  docs: Documentation changes only
  style: Changes that do not affect the meaning of the code
  refactor: A code change that neither fixes a bug or adds a feature
  perf: A code change that improves performance
  test: Adding missing tests
  chore: Changes to the build process or auxiliary tools & libraries such as documentation generation.
? Denote the scope of this change($location, $browser, $compile, etc)

? Write a short, imperative tense description of the change:

? Provide a longer description of the change:

? List any breaking changes or issues closed by this change:

### if successful you should see
commit succeeded

Now if you go to one of your favorite techs and look at their repository's Releases tab if they are using semantic-release it will be formatted similar to the commitizen interface you just filled out: example