Skip to content

Instantly share code, notes, and snippets.

@iaincollins

iaincollins/CONTRIBUTING.md

Created October 26, 2018 09:32
Show Gist options
  • Save iaincollins/ffbf82f1d142ae965042f9d63fa6d276 to your computer and use it in GitHub Desktop.
Save iaincollins/ffbf82f1d142ae965042f9d63fa6d276 to your computer and use it in GitHub Desktop.
Download ZIP
How to Contribute
Raw
CONTRIBUTING.md

How to contribute

See the instructions in README.md for how to run the code.

When developing a feature, you should start by scoping out a spec, developing tests against that spec and writing code against the tests. Working with others to review the spec before starting development is encouraged.

Raise a Pull Request

  1. When you create a branch, it should reflect the nature of the change.
  • We use feature and hotfix branch prefix naming convention for branches, inspired by git-flow.
  • We do not use develop/stable/release branches in this project - master is continuously deployed on commit.
  • All branches should be kept up to date with changes in the master branch.

For example:

  • For features (including refactoring) use: feature/{feature-name} (e.g. feature/new-logo-image)
  • For bug fixes use: hotfix/{bug-name} (e.g. hotfix/invalid-logo-image).
  1. If developing a feature, ensure you have a spec and tests for your new code.
  2. Ensure linting rules (npm run lint) an tests (npm run test) all pass.
  3. Pull from master to ensure your branch includes the latest changes from the master branch.
  4. Review your commit messages (see Use Git effectively below).

When the above are done, Raise a pull request on GitHub and fill out the pull request template when prompted. You can get in touch with one of the team members to prompt them to review your PR.

If you have access to Jira and a ticket ID, add the URL of the Pull Request to the ticket and update the ticket status to show it is waiting for review.

Use Git effectively

When writing a commit message:

  • Keep the first line under 50 characters.
  • Do not end the subject line with a period.
  • Capitalize the subject line and each paragraph.
  • Use the imperative mood in the subject line (e.g. 'Fix logo image', 'Add logo image').
  • Separate subject from body with a blank line.
  • Wrap lines at 72 characters.
  • Use the body to explain what and why you have done something.
  • In most cases, you can leave out details about how a change has been made.
  • Include links / IDs of relevant stories or bug reports.
  • Before you push changes to your feature branch on GitHub, consider squashing commits locally.

Squashing commits to group changes together meaningfully can provide a more concise and useful history.

Approval

Your changes will need to be reviewed and approved by someone who has not worked on the pull request before it is accepted into the master branch. It will need to pass the checklist set out in the pull request template:

  • Specification Reviewed
  • Test Code Reviewed
  • Code Reviewed
  • Interface Changes Reviewed
  • Architectural Decision Record Reviewed

If you need to document a design decision (e.g. introducing a new library or pattern) you should include an Architectural Decision Record in the docs/adr directory. See docs/adr/template.md for a template.

Deployment

  1. As soon your pull request is approved you will be able to incorporate your changes into the master branch.
  2. You (as the creator of the Pull Request) should rebase and merge in your pull request, once it is approved.
  3. Use the rebase and merge option (rather than merge commit or squash) to merge changes into master.
  4. Delete your branch after rebase and merge is complete.
  5. Your changes will go live automatically.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment