Skip to content

Latest commit

 

History

History
64 lines (41 loc) · 4.18 KB

CONTRIBUTING.md

File metadata and controls

64 lines (41 loc) · 4.18 KB

Contributing

Thank you for your interest in contributing to the library!

Table of Contents

Setup

  1. Fork the repository
  2. Clone your new forked repository to your local computer
  3. Set the benmvp repository as your branch's upstream branch: git remote add upstream https://github.com/benmvp/benmvp-cli.git
  4. Navigate to the root directory of your newly cloned repository: cd /path/to/benmvp-cli
  5. npm install to install local dependencies

Using branches to submit changes

To work on changes, create a new branch on your local repository. git checkout -b <your-new-branch-name>

Keeping your local repository up to date

To ensure your branch never gets out of sync with https://github.com/benmvp/benmvp-cli's master, ensure that you have your upstream set properly (see the Setup step)

  1. git checkout master (you may have to stash or commit your local changes)
  2. git pull upstream master
  3. git checkout <your-new-branch-name>
  4. git rebase master
  5. If you've stashed changes, unstash them now, otherwise your branch should now be up to date

Always try to keep your master "clean" by only pulling changes directly from upstream into your master branch and rebasing those changes onto your working branch.

It is always a good idea to pull the upstream branch in to your master branch before creating a new feature branch to work from. This will minimize the chances of encountering merge conflicts.

Creating Issues

Create issues to file bugs, changes, and proposals.

Before opening a new issue, please search to see if there has been previous discussion about the same feature or issue. If so, please contribute to the discussion there.

If nothing is found, feel free to open a new issue and fill out the issue template to the best of your ability.

Working on and submitting changes

When starting on improvements or new features that are non-trivial, it is always a good idea to first discuss the changes you wish to implement by opening a github issue before getting started.

If you've found a bug or feature you'd like to work on in our github issue tracker, please comment on the issue to let others know that you'd like to work on it.

While implementing fixes, please try to change as little code as possible. This helps speed up the review process and helps diminish the chance of additional bugs.

Please try to conform to the coding style of the code base.

Steps to submit:

  1. Please ensure that your changes are fully covered by one or more unit tests.
  2. Check to make sure that your changes are documented properly (inline comments for interesting lines, READMEs, etc.)
  3. Run npm test to ensure that all tests pass, the linter is satisfied and your changes are typescript compliant.
  4. PR titles must be prefixed by the type of changes the PR contains followed by the scope of what the PR touches. We are following the angular commit guidelines. Please use one of feat, fix, docs, style, refactor, perf, test, chore as the prefix. The "()" is the the direct product your changes affect. Example: chore(build): Add encrypted ssh key for semantic-release because its a chore and it touches the build. For multiple scope items, you can comma separate 2 or 3 but if there are more than that please use a * instead.
  5. Please use a closing issue keyword to indicate the issue that your fix addresses in the description section of the pull request template. Example: fixes #32 to close issue #32