Skip to content

Latest commit

 

History

History
136 lines (96 loc) · 5.45 KB

CONTRIBUTING.md

File metadata and controls

136 lines (96 loc) · 5.45 KB

Contributing to myDevicesIoT

Here are guidelines we would like you to follow:

Git Workflow

This repository has three main branches: master (production), staging, and develop.

Normal workflow: develop -> rc -> staging -> master (tag latest commit)

Feature Branches

New features should have its own branches with name format: [Type]/[branch-name] where Type follows commit type.

Release Candidate Branches

RC branch is forked from develop before merging into Staging.

  • Semantic Versioning MAJOR.MINOR.PATCH
    • MAJOR version when you make incompatible API changes,
    • MINOR version when you add functionality in a backwards-compatible manner, and
    • PATCH/HOTFIXES version when you make backwards-compatible bug fixes or hotfixes.
  • Naming convention example: rc/v2.1.1

Release Tag

Release tag should be made on the latest in master after merging staging to master.

Naming convention with semantic versioning: release-YYYYMMDD-vX.Y.Z

Hotfix branch

Branch off of master and upon completion of fix, merge into master (tag hotfix), develop, and staging as a merge commit.

Submitting a Pull Request (PR)

Before you submit your Pull Request (PR) for a non-hotfix task, consider the following guidelines:

  1. Branch off of develop as feat/my-new-feature
  2. Add your update, including appropriate test cases.
  3. Run the full test suite and ensure all tests pass.
  4. Commit your changes using a descriptive commit message that follows our commit message conventions.
  5. Open PR to develop and make any requested changes (if any)

Merging your pull request (non-hotfix)

If you're merging a PR that addresses one single feature or bugfix:

  1. Before merging your PR, please change the name:
  • The name must follow commit message conventions
  • -or- if the PR is specific to one Jira card, change the name to the following format: SS-XXXX: [Jira Card Title], sample: SS-2158: Contact Only contact added via web with missing email address adds incorrectly and add a link to the Jira card in the PR description.
  1. Squash and Merge your changes into develop, this will make it easier to revert specific features, bugfixes, or Jira tasks if the need arises.

If you're merging a PR that addresses multiple features and/or bugfixes:

  1. Use your best judgement whether to Squash and Merge or Create a merge commit
  • Squash and merge will merge your changes into develop as a single commit
  • Create a merge commit will merge your changes into develop including all the commits made in your main branch.

Merging your hotfix pull requests

When submitting your PR for a hotfix tasks, please follow the following:

  1. Branch off the master branch
  2. Open PR to master
  3. After hotfix is merged into master, merge the hotfix changes to develop as a merge commit type.

Git Commit Guidelines

We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history.

Commit Message Format

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 is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

The footer should contain a closing reference to an issue if any.

Samples:

fix(location): return locations on GET requests

Revert

If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Type

Must be one of the following:

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

Scope

The scope could be anything specifying place of the commit change. For example company, location, sharing, etc...

Subject

The subject contains succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize first letter
  • no dot (.) at the end

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.