Skip to content
This repository has been archived by the owner on Jan 29, 2023. It is now read-only.

Latest commit

 

History

History
65 lines (47 loc) · 2.59 KB

CONTRIBUTING.md

File metadata and controls

65 lines (47 loc) · 2.59 KB
Raw

Contributing

  1. Familiarize yourself with the codebase and review oclif’s Getting Started documentation.
  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. DEVELOPING 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, below). Note: This step is recommended but technically not required if contributing using a fork.
  6. Edit the code in your fork.
  7. Write appropriate tests for your changes. Try to achieve at least 95% code coverage on any new code. No pull request will be accepted without unit tests.
  8. Sign the Contributor’s License Agreement (see CLA, below).
  9. Send us a pull request when you are done. We’ll review your code, suggest any needed changes, and merge it in.

CLA

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

Branches

  • We work in develop.
  • Our released (AKA production) branch is master.
  • Our work happens in topic branches (feature and/or bug-fix).
    • feature as well as bug-fix branches are based on develop
    • keep your branches 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:

    1. Are based on develop.
    2. Will be 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 master

  • When a development cycle finishes, the content of the develop branch will become the master branch
$ git checkout master
$ 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/master
$ git push origin master

Pull Requests

  • Develop features and bug fixes in topic branches.
  • Topic branches can live in forks (for external contributors) or within this repository (for 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.