Conventional Commits

This is a mix task that will open a REPL allowing developers to write commit messages following conventional commits

Setup

Usage

Conventional Commit

A conventional commit will have the following structure

<type>[optional scope] : <description>

[optional body]

[optional footer(s)]

For example:

feat(logging): Updating logging module

- Updated `parse_log/3` to stream logs. This allows for more consistent load on the backend.

Author: W3NDO
Refs: #123

The .commit.exs file

This is a file that will specify parts of a commit that may be required by the user's code base. For example, if your organisation needs that all commits contain a body, then it is included in the .commit.exs file under required: []

[
  required: [],
  footer_fields: [:author, :reviewed_by, :refs],
  breaking_change_in_footer: false
]

required field keys

body : Used if the commit requires a body footer: Used if the commit requires a footer scope : Used if the commit requires a scope

If the .commit.exs file does not exist, you can specify required parts of the commit using these flags: -f or --footer : Footer required -b or --body : Body required -s or --scope: Scope required.

footer_fields

These will be used to specify fields that should be included in the footer. It is ignored if :footer is not in required.

breaking_change_in_footer

This is a boolean that specifies if in the footer ofa commit with a breaking change the tag BREAKING CHANGE is included. By default it is false, but all breaking change commits will include a ! before the description

Task Options

What this mix task doesn't do

  1. Push your changes upstream.
  2. Add your changes to staging. (WIP)

Contributing

Visit the issues tracker to see which issues are outstanding. You are welcome to file new issues as well!