Skip to content

Latest commit

聽

History

History
57 lines (36 loc) 路 2.59 KB

CONTRIBUTING.md

File metadata and controls

57 lines (36 loc) 路 2.59 KB
Raw

Contributing

To test the CLI application, run the dev script:

npm run dev -- [cli arguments can be passed after the double-dash]

Writing commit messages

resume-cli uses semantic-release to automate version management and package publishing. semantic-release determines the next version number and release notes based on the commit messages, meaning a convention must be followed.

resume-cli uses the Conventional Commits specification to describe features, fixes, and breaking changes in commit messages. A typical commit title is structured as follows:

<type>[optional scope]: <description>

Type

Must be one of the following:

  • fix: for a bug fix (corresponds to a PATCH release);
  • feat: for a new feature (corresponds to a MINOR release);
  • other non-release types such as build:, docs:, refactor:, test: and others (see recommended).

Appending a ! after the type/scope indicates a breaking change (corresponds to a MAJOR release). A breaking change can be part of commits of any type.

Scope

A scope may be provided to a commit鈥檚 type, to provide additional contextual information and is contained within parenthesis, e.g. feat(theme): add ability to specify theme.

Description

The description contains a concise explanation of the changes:

  • use the imperative, present tense, e.g. "change", not "changed" nor "changes";
  • don't capitalize the first letter;
  • no period (.) at the end.

Submitting a pull request

The pull request title should follow the same commit title conventions, as it will become the merge commit title, and thus be used to determine the type of changes in the codebase.

Because pull request commits are squashed on merge, you don't need to follow this convention on every feature branch commit, but certainly do for the merge commit.

Merging a pull request

Before merging a pull request:

  1. make sure the pull request branch is synced with the target branch;
  2. make sure all pull request checks are passing;
  3. merge using the squash and merge option;
  4. assuming the pull request title is following the title conventions:
    1. do not modify the merge commit title field, keeping the pull request ID reference;
    2. empty the merge commit message field, only adding content if relevant (e.g. breaking changes).