Skip to content

Latest commit

 

History

History
121 lines (94 loc) · 4.16 KB

CONTRIBUTING.md

File metadata and controls

121 lines (94 loc) · 4.16 KB
Raw

Contributing

General Workflow

  1. Fork the repo
  2. Cut a namespaced feature branch from master
  • bug/...
  • feat/...
  • test/...
  • doc/...
  • refactor/...
  1. Make commits to your feature branch. Prefix each commit like so:
  • (feat) Add a new feature
  • (fix) Fix inconsistent tests [Fixes #0]
  • (refactor) ...
  • (cleanup) ...
  • (test) ...
  • (doc) ...
  1. When you've finished with your fix or feature, Pull down from upstream master and resolve any merge conflicts. submit a [pull request][] directly to master. Include a description of your changes.
  2. Your pull request will be reviewed by another maintainer. The point of code reviews is to help keep the codebase clean and of high quality and, equally as important, to help you grow as a programmer. If your code reviewer requests you make a change you don't understand, ask them why.
  3. Fix any issues raised by your code reviwer, and push your fixes as a single new commit.
  4. Once the pull request has been reviewed, it will be merged by another member of the team. Do not merge your own commits.

Detailed Workflow

Fork the repo

Use github’s interface to make a fork of the repo, then add that repo as an upstream remote:

git remote add upstream https://github.com/superFruitPower/spaceShare.git

Cut a namespaced feature branch from master

Your branch should follow this naming convention:

  • bug/...
  • feat/...
  • test/...
  • doc/...
  • refactor/...

These commands will help you do this:

# Creates your branch and brings you there
git checkout -b `your-branch-name`

Make commits to your feature branch.

Prefix each commit like so

  • (feat) Adds a new feature
  • (fix) Fixes inconsistent tests [Fixes #0]
  • (refactor) ...
  • (cleanup) ...
  • (test) ...
  • (doc) ...

Make changes and commits on your branch, and make sure that you only make changes that are relevant to this branch. If you find yourself making unrelated changes, make a new branch for those changes.

Commit Message Guidelines

  • Commit messages should be written in the present tense; e.g. "Fixes continuous integration script".
  • The first line of your commit message should be a brief summary of what the commit changes. Aim for about 70 characters max. Remember: This is a summary, not a detailed description of everything that changed.
  • If you want to explain the commit in more depth, following the first line should be a blank line and then a more detailed description of the commit. This can be as detailed as you want, so dig into details here and keep the first line short.

Pull down from the master branch

  • Pull down from the upstream master branch and resolve any merge conflicts.

Make a pull request

Make a clear pull request from your fork and branch to the upstream master branch, detailing exactly what changes you made and what feature this should add. The clearer your pull request is the faster you can get your changes incorporated into this repo.

At least one other person MUST give your changes a code review, and once they are satisfied they will merge your changes into upstream. Alternatively, they may have some requested changes. You should make more commits to your branch to fix these, then follow this process again from rebasing onwards.

Once you get back here, make a comment requesting further review and someone will look at your code again. If they like it, it will get merged, else, just repeat again.

Thanks for contributing!

Guidelines

  1. Uphold the current code standard:
    • Keep your code [DRY][].
    • Apply the [boy scout rule][].
    • Follow STYLE-GUIDE.md
  2. Run the [tests][] before submitting a pull request.
  3. Tests are very, very important. Submit tests if your pull request contains new, testable behavior.

Checklist:

This is just to help you organize your process

  • Did I cut my work branch off of master (don't cut new branches from existing feature brances)?
  • Did I follow the correct naming convention for my branch?
  • Is my branch focused on a single main change?
  • Do all of my changes directly relate to this change?
  • Did I write a clear pull request message detailing what changes I made?