Skip to content

Latest commit

 

History

History
126 lines (96 loc) · 3.67 KB

GIT_RULES.md

File metadata and controls

126 lines (96 loc) · 3.67 KB

Git rules

The reasons for these conventions:

  • automatic generating of the changelog
  • simple navigation through git history (e.g. ignoring style changes)

Git branches

Branch names in this project must adhere to this contract:

  • Primary (no commit and push allowed)
    • master
    • develop
    • release/{VERSION}
  • Secondary (require for every ticket and need to be create as shown below)
    • feature/#{TICKET_ID}-{DESCRIPTION}
    • fix/#{TICKET_ID}-{DESCRIPTION}
    • hotfix/#{TICKET_ID}-{DESCRIPTION}

Git Commit

Format Example 
<type>(<scope>): <subject>

<body>

<footer>
 
fix(middleware): #2310 ensure Range headers adhere more closely to RFC 2616

Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.

Fixes #2310

Message subject (first line)

The first line cannot be longer than 72 characters, the second line is always blank and other lines should be wrapped at 80 characters.

The type and scope should always be lowercase as shown in the example.

The subject need to begin with the ticket id that require this commit.

Allowed <type> values:

  • feat (new feature for the user, not a new feature for build script)
  • build (build systeme like vite.js, yarn)
  • fix (bug fix for the user, not a fix to a build script)
  • docs (changes to the documentation)
  • style (formatting, missing semi colons, etc… no production code change)
  • refactor (refactoring production code, eg. renaming a variable)
  • test (adding missing tests, refactoring tests; no production code change)
  • chore (updating grunt tasks etc… no production code change like .gitignore)
  • perf (performance improvement)
  • ci (continuous integration like Github Action, Gitlab Pipeline, Travis, Circle, BrowserStack, SauceLabs…)

Example <scope> values:

  • init
  • runner
  • watcher
  • config
  • web-server
  • proxy
  • etc…

The <scope> can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted. In smaller projects the <scope> is empty.

Message body

  • uses the imperative, present tense: "change" not "changed" nor "changes"
  • includes motivation for the change and contrasts with previous behavior

For more info about message body, see:

Message footer

Breaking changes

All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes.

BREAKING CHANGE:

`port-runner` command line option has changed to `runner-port`, so that it is
consistent with the configuration file syntax.

To migrate your project, change all the commands, where you use `--port-runner`
to `--runner-port`.

Referencing issues

Referenced issues should be listed on a separate line in the footer prefixed with "Closes" keyword like this:

Closes #234

or in the case of multiple issues:

Closes #123, #245, #992

This document is based on AngularJS Git Commit Msg Convention. See the commit history for examples of properly-formatted commit messages.