Skip to content

Issue flow

Jump to bottom
Tetiana Polishchuk edited this page Nov 3, 2020 · 11 revisions

Start

  1. Get the issue to work, add yourself to the Assignees
  2. Create a new branch, include the task number and a short description in the name, for example:

git checkout -b 'issue_4_routing_setup'

Format of the commit message

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

A commit message consists of a header, a body and a footer, separated by a blank line.

Message header

The message header is a single line that contains succinct description of the change containing a type, an optional scope and a subject.

<type>

This describes the kind of change that this commit is providing.

  • feat (feature)
  • fix (bug fix)
  • docs (documentation)
  • merge
  • style (formatting, missing semi colons, …)
  • refactor
  • release
  • test (when adding missing tests)
  • chore (maintain)

<scope> (optional)

Scope must be a noun specifying section of the codebase of the commit change surrounded by parenthesis, e.g., fix(parser).

<subject>

This is a very short description of the change.

  • Subject line should be no longer than 50 characters
  • Use imperative, present tense: “change” not “changed” nor “changes”
  • Don't capitalize first letter
  • No dot (.) at the end

Examples

feat(lang): add polish language
refactor: subsystem X for readability
docs: update getting started documentation
merge: pull request #123 from user/branch
refactor: remove deprecated methods
release: version 1.0.0

Message body

Use the body to explain motivation for the change and contrasts with previous behavior.

  • Focus on making clear the reasons why you made the change.
  • In most cases, you can leave out details about how a change has been made.
  • Just as in <subject> use imperative, present tense: “change” not “changed” nor “changes”.
  • Wrap the body at 72 characters to allow for indentation in command line tools.

Message footer

  1. BREAKING CHANGE
  • All breaking changes have to be mentioned as a breaking change block in the footer, which should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then the description of the change, justification and migration notes.
  1. Referencing issues
  • Closed bugs should be listed on a separate line in the footer prefixed with "Closes" keyword like this:

Closes #234

  • Or in case of multiple issues:

Closes #123, #245, #992

Example:

Closes #392 Breaks foo.bar api, foo.baz should be used instead

Pull request

  1. The title should contain the task number and a short description, for example:

    #4 routing base implementation

  2. In the description we indicate the changes made (you can repeat the texts of the commits or describe changes more detailed),

    if you specify the issue number using #, a link to it will be added to the pull request, for example:

    issue #4

    • install react-router-dom
    • create component Main with basic markup
    • add routing logic

    if necessary, you can describe:

    • related tasks, for example:

      dokazovi-fe#2

    • dependence on other PR, for example:

      depence on PR #3

    • prerequisites (why did you choose this library, which source is worth reading for a better understanding of your changes):

      a new approach to routing was used here, you can read about it in this article

    • the problems you was facing

Useful links

Linking a pull request to an issue

Autolinked references and URLs

Git Commit Message Conventions

Clone this wiki locally