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
- 32 configurable rules
- lint single commits or ranges
- friendly error messages
- https://github.com/marionebl/commitlint
