Skip to content

Latest commit

 

History

History
71 lines (47 loc) · 2.65 KB

CONTRIBUTING.md

File metadata and controls

71 lines (47 loc) · 2.65 KB
Raw

Contributing to devto-clone

If anyone wants to contribute add a feature request in the issues. I will comment I accept on it and then you can build the feature I won't build it but you have to release an article on how you build that feature.

Before doing any changes to the codebase you have to fork devto-clone repo and clone it.We follow the Conventional Commits specification.

A commit message consists of a header, body and footer. The header has a type, scope and subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

Type

If the prefix is feat, fix or perf, it will appear in the changelog. However if there is any BREAKING CHANGE, the commit will always appear in the changelog.

Must be one of the following:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Scope

The scope can be anything specifying place of the commit change. Usually it will refer to a component but it can also refer to a utility.

Subject

The subject contains succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • do not capitalize first letter
  • do not place a period . at the end
  • entire length of the commit message must not go over 50 characters
  • describe what the commit does, not what issue it relates to or fixes
  • be brief, yet descriptive - we should have a good understanding of what the commit does by reading the subject

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Examples

docs(changelog): update steps to update
feat(toast): add 'buttons' property
fix: typo in input property
revert: feat(skeleton-text): add animated property