Conventional Commits

About

  • Issues with git commit -m
  • The conventional commit format
  • Stay consistent with commitlint
  • Step-by-step CLI commit tool

git commit -m "something something"

git commit -m "fix"

git commit -m "clean up asdasd"

Consistent, sensible commit messages are hard

 

commit -m free form does not help too much

type(scope?): subject

chore: add pull request template

fix(header): make logo clickable

type(scope?): subject

chore: add pull request template

fix(header): make logo clickable

type(scope?): subject

  • Describes the category of your change
  • Commonly used: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test

type(scope?): subject

chore: add pull request template

fix(header): make logo clickable

type(scope?): subject

  • Optional
  • Describes the module affected by your change
  • Highly project specific

type(scope?): subject

chore: add pull request template

fix(header): make logo clickable

type(scope?): subject

  • Terse description
  • Avoid repeating information from type and scope
  • Describe what the software does after your change

Perks

  • High quality commit messages
  • Ensure critical information included
  • Add Context to Pull Requests
  • Smaller commits via type and scope boundaries
  • Format easily parsed by tooling (auto changelog)

Keeping consistency

with commitlint

CLI tool for easy conventional commits

Thanks!

Made with Slides.com