Riupress UI

Appearance

Conventional commits ​

Conventional commits - is a specification of adding, readable for man and computer, meaning to the information in the process of introducing changes in the GIT repository. Below is a description of the steps/information added when saving information to the GIT repository using the pluginConventional Commits.

step 1 - change type ​

The type defines the type of code changes and defines whether the changes introduced are a new functionality or maybe some amendment. Below is a list of types of messages that can be used:

  • feat – new functionality;
  • fix – amendment to the existing functionality;
  • docs – changes only in the documentation;
  • chore – changes that do not affect the content of the source code or tests (e.g. pack update);
  • refactor – changes that are not both fixes and new functionalities;
  • test – everything related to tests;
  • perf – changes in the code to improve performance;
  • style – all kinds of code formatting, white characters, commas or missing diameters;
  • ci – changes for the CI needs (configurations, scripts);
  • build – changes affecting the build process;
  • revert – revert of recent changes.

step 2 - change scope (scope) ​

It should be a noun determining the place in the code.For example, if we change something in routing, we can put information in the content that the change concerns this particular area of the application (e.g. feat(routing)). scope is placed in a round bracket after defining the type of commit.

scopes can be defined in the settings for the editor. Sample file .vscode/settings.json containing two places in the code:

json
{
  "conventionalCommits.scopes": ["settings", "docs"]
}

If you use the functionality of workspace in VSCode, the list of ranges will be defined in the working space configuration file.

step 3 - gitmoji ​

In this optional step, we can put at the beginning of a brief description of the Emoji change defining change.

step 4 - opis (description) ​

Comment/description of the change that should:

  • concisely describe the changes that have taken place in the code;
  • be in the abandonment in the present tense. This means that there should be no such thing as added polish translations or adding polish translations. Correct is: add polish translations.

step 5 - extended description ​

The extended description is an optional field in which we can describe commit in detail.

step 6 - BREAKING CHANGES ​

In the case that commit contains a description of the key change, the MAJOR version is raised.

Relacja do wersji semantycznych ​

There is a close relationship between conventional commits, a semantic releases, where we generate edition versions:

  • fix - this type of message is treated as a PATCH type version;
  • feat - this type of message is treated as a MINOR type version;
  • a message containing BREAKING CHANGE is treated as a version of MAJOR;

Husky - commit validation ​

Husky - automatically lint your commit messages, code, and run tests upon committing or pushing.