Skip to content

GIT and Contributing

Jump to bottom
Vojtech Mašek edited this page Aug 19, 2019 · 2 revisions

GIT

  • git adding and generating ssh key help

  • commit messages format convention is similar to the angular's, commit messages in this format can be later used to generate a changelog (example)

  • GIT cheatsheet (pdf here in repo)

Commits

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

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

The header (short commit message) is required and needs to have a correct syntax.

The body is optional. It should include the motivation for the change and contrast this with previous behavior.

The footer should contain a closing reference to an issue if any. For example: closes #42 or fixes #110, fixes #111 and closes #125 can be separated from this or each on one line. Do not forget to use a keyword for each issue, else it will not be recognized and tagged correctly. It usually also includes a description of what has changed mentioning the breaking changes.

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

A detailed explanation can be found in this document.

Commit types

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (whitespace, 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 or correcting existing tests
  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, NPM)
  • ci: Changes to our CI configuration files and scripts (example scopes: Wercker, BrowserStack, SauceLabs)
  • chore: Other changes that don't modify src or test files

Commit subject

The subject contains a succinct description of the change:

  • please do NOT use words that will lead the subjects to be too trivial or meaningless like fixed toolbar, user login fix or authorization change (beware when using fix, fixed, added, change, ...)
  • use the imperative or present tense: "change" not "changed" nor "changes"
  • please don't capitalize the first letter and don't use dot (.) at the end

examples:

  • fix(login): signing by pressing enter on username/pass input is now possible
  • feat(translate): translations module with lang changing and small demo
  • fix(payslip): corrected payslip height
  • feat(top-bar): top-bar is now responsive
  • refactor(training): moment is used instead of Date
  • more complex example
fix(tooltip): provide a maximum width

Adds a `max-width` to the tooltip, in order to wrap long lines of text. The value is arbitrary since it was not in the spec.

fixes #2671
closes #123

GIT flow (branches)

Branching system is separated into:

  • master branch
  • feature branches
    • here is located development of new features
    • usually starts from the master branch (sometimes can start from another feature branch if needed)
    • after finishing the feature it can be merged via a pull request (PR) back into master
    • naming: feature/<name-of-feature-branch> or more specifically feature/<scope>-<simplified-task> for example: feature/top-bar
  • bugfix branches
    • used for fixing (non-hotfix) bugs
    • otherwise same rules apply as for feature branches

Hotfixes are performed directly on master branch. Releases are tagged using git tag (versioned according to semver).

GIT flow

Issues

  • use the [<scope>]: <subject> format
    • both <scope> and <subject> are in lower case letters (except abbreviations like URL, HTTP, ...)
    • <scope> is the dash-case name of the logical part of the project targeted by the issue
    • <subject> is the brief description of the issue purpose applied to the <scope>
  • body should contain more detail description with specified steps for implementation or reproduction of bug

Pull requests

  • it is usually the only way how you can contribute your code our repositories
  • it is automatically built, deployed, checked and then reviewed by its reviewer (or other colleagues)
  • should have commit like format (see commit name syntax)
  • you should tag at least one reviewer for each PR
Clone this wiki locally