Contributing

June 8, 2017 · View on GitHub

Setup Development Environment
Version Control
Your First Pull Request

Setup Development Environment

Git User
GPG Keys

Git User

1. Tell Git who you are

git config --global user.name "Your Name"
git config --global user.email "example@address.com"

GPG Keys

1. Install GPG Tools -- do a customized install and deselect GPGMail.

2. Tell Git to use the gpg2 that comes with GPG Tools

git config --global gpg.program /usr/local/MacGPG2/bin/gpg2

3. Generate a GPG key using Applications/GPG Keychain

4. Tell Git to use your new GPG Key and auto-sign all commits

git config --global user.signingkey KEY_ID_FROM_STEP_3
git config --global commit.gpgsign true

5. Add Keys to Github

https://help.github.com/articles/adding-a-new-gpg-key-to-your-github-account/

https://help.github.com/articles/generating-a-new-gpg-key/

The master branch should be considered the most up-to-date stable version of the software. No active development should take place on directly master and the latest commit should always be tagged to a release.

Hotfix should be branched off of master

The next branch should be considered the most up-to-date development version of the software. No active development should take place on directly on next.

All development should be branched off of next
next should be rebased with master after a hotfix

Branches

All development should happen on a branch off of next. Branch names should include a ticket number if possible: TICKET-##-couple-words or my-update.

git checkout -b TICKET-11-my-feature

Branches should be rebased with next if they get out of date.
Branches should be merged into next when they are completed.

Hotfix

A hotfix is a branch that uses master as a base instead of next.

Commits

Commit messages should make it easy for some one to scan through a commit log and understand the current state of the code.
When only changing documentation, include [ci skip] in the commit description
Consider starting the commit message with an applicable emoji:
- :tada: :tada: for the initial commit
- :green_heart: :green_heart: when fixing the CI build
- :white_check_mark: :white_check_mark: when adding tests
- :arrow_up: :arrow_up: when upgrading dependencies
- :arrow_down: :arrow_down: when downgrading dependencies
- :shirt: :shirt: when removing linter warnings
- :recycle: :wrench: when refactoring
- :wrench: :wrench: when updating tooling
start with one of the following emojis to add your commit to the change log:
- :racehorse: :racehorse: when improving performance
- :sparkles: :sparkles: when adding a new feature
- :bug: :bug: when fixing a bug
- :books: :books: when adding documentation
- :globe_with_meridians: :globe_with_meridians: when adding internationalization
you can use multiple emojis but only with first will be considered when generating the change log
you can look at gitmoji for inspiration

Examples

Commits have the following structure:

:icon: [TICKET-1,TICKET-2] one line description

Longer description
- list of changes
- one more thing

Examples of valid commits:

:sparkles: [TICKET-1,TICKET-2] adds new page to that page

Adds new feature to do that thing that we wanted to do:
- That one thing it does
- that other thing it does

:bug: [TICKET-1] fixes bug with thing

:racehorse::wrench: better production mode

:shirt: fixes eslint in tests

Code Review

All branches should be pushed to Github for code review.
All branches need to be reviewed and signed-off before they can be considered complete.
Any branches containing significant changes will also need to be QA'ed.