The perks of committing with conventions

Mario

  • Free Radical
  • Principal Product Engineer
  • @SinnerSchrader

 

  • ūüĎ®‚ÄćūüíĽ¬†ūüŹĄ

This talk

  • Issues with commit -m
  • The conventional commit format
  • Use commit messages for project automation
  • Stay consistent with commitlint

git commit basically is 

<textarea required>
git commit -m "fix"
git commit -m "updated"
git commit -m "clean up"

Snark 

Missing information

Placeholder messages

Consistent, sensible commit messages are hard

 

commit -m free form does not help too much

conventional commit format

type(scope?): subject

chore: run tests on travis ci

fix(server): send cors headers

chore: run tests on travis ci

fix(server): send cors headers

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: run tests on travis ci

fix(server): send cors headers

type(scope?): subject
type(scope?): subject
  • Describes the module affected by your change
  • Highly project specific
  • e.g. changed package in Mono-Repo, component in component library, etc.

chore: run tests on travis ci

fix(server): send cors headers

type(scope?): subject
type(scope?): subject
  • Terse description
  • Avoid repeating information from type and scope
  • Describe what the software does after your change¬†

Conventional commit format

  • What type of changes am I committing?
  • What scope is affected by my changes?
  • subject: When applied, the software will ...

Conventional commit format

  • 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

Tooling

Automatic changelogs

Automatic releases

  • lerna
  • standard-version
  • semantic-release
  • conventional-github-releaser
  • conventional-recommended-bump

Automatic releases

BREAKING CHANGE        Major release

feat:                                   Minor release               

fix:                                      Patch Release

other                                 Patch/No Release

Keeping consistency

  • commitlint
  • 32 configurable rules
  • lint single commits or ranges
  • friendly error messages

 

Use case: define allowed scopes

// commitlint.config.js

module.exports = {
  extends: ['angular'],
  rules: {
    'scope-enum': [
        2, 
        'always', 
        ['server', 'client']
    ]
  }
};

Use case: define allowed scopes

echo "fix: send cors headers" | npx commitlint
‚úĒ¬† ¬†found 0 problems, 0 warnings

 

echo "fix(server): send cors headers" | npx commitlint
‚úĒ¬† ¬†found 0 problems, 0 warnings

 

echo "fix(foo): some message" | npx commitlint
‚úĖ¬† ¬†scope must be one of [server, client] [scope-enum]
‚úĖ¬† ¬†found 1 problems, 0 warnings

Wrap up

  • Author consistent, complete commit messages
  • Keep changes small by fitting them into a schema
  • Help coworkers understand your changes better
  • Power automation with commit messages¬†
  • Use ready-made tooling for changelogs, releases, commit prompts, linters

Thanks!

The perks of committing with conventions

By Mario Nebl

The perks of committing with conventions

git is an awesome tool to keep around the history of your project. It asks one small thing in return, though: A commit message. Let's talk about how we can make better use of git by adopting commit conventions and the resulting opportunities for project automation. We'll also explore tools that help you to adhere and make the most of your glorious new commit style.

  • 11,298
Loading comments...

More from Mario Nebl