Skip to content

Latest commit

 

History

History
71 lines (51 loc) · 3.1 KB

CONTRIBUTING.md

File metadata and controls

71 lines (51 loc) · 3.1 KB
Raw

Contributing

  1. Familiarize yourself with the codebase by reading the docs, in particular the development doc.
  2. Create a new issue before starting your project so that we can keep track of what you are trying to add/fix. That way, we can also offer suggestions or let you know if there is already an effort in progress.
  3. Fork this repository.
  4. The README has details on how to set up your environment.
  5. Create a topic branch in your fork based on the correct branch (usually the develop branch, see Branches section below). Note, this step is recommended but technically not required if contributing using a fork.
  6. Edit the code in your fork.
  7. Sign CLA (see CLA below)
  8. Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in.

Committing

  1. We enforce commit message format. We recommend using commitizen by installing it with npm install -g commitizen and running npm run commit-init. When you commit, we recommend that you use npm run commit, which prompts you with a series of questions to format the commit message. Or you can use our VS Code Task Commit.
  2. The commit message format that we expect is: type: commit message. Valid types are: feat, fix, improvement, docs, style, refactor, perf, test, build, ci, chore and revert.
  3. Before commit and push, Husky runs several hooks to ensure the commit message is in the correct format and that everything lints and compiles properly.

CLA

External contributors will be required to sign a Contributor's License Agreement. You can do so by going to https://cla.salesforce.com/sign-cla.

Branches

  • We work in develop.
  • Our released (aka. production) branch is main.
  • Our work happens in topic branches (feature and/or bug-fix).
    • feature as well as bug-fix branches are based on develop
    • branches should be kept up-to-date using rebase
    • see below for further merge instructions

Merging between branches

  • We try to limit merge commits as much as possible.

    • They are usually only ok when done by our release automation.

  • Topic branches are:

    1. based on develop and will be
    2. squash-merged into develop.

  • Hot-fix branches are an exception.

    • Instead we aim for faster cycles and a generally stable develop branch.

Merging develop into main

  • When a development cycle finishes, the content of the develop branch becomes the main branch.
$ git checkout main
$ git reset --hard develop
$
$ # Using a custom commit message for the merge below
$ git merge -m 'Merge -s our (where _ours_ is develop) releasing stream x.y.z.' -s ours origin/main
$ git push origin main

Pull Requests

  • Develop features and bug fixes in topic branches.
  • Topic branches can live in forks (external contributors) or within this repository (committers). ** When creating topic branches in this repository please prefix with <developer-name>/.

Merging Pull Requests

  • Pull request merging is restricted to squash & merge only.