Fool Proof Rebase Strategy

## Git Workflow

We want to closely monitor what gets merged down to `master` branches and keep
 our commit history as clean as possible. To accomplish this we can employ a few best
 practices to ensure we don't see large numbers of useless `merge` commits and in addition
 to that it will keep the ordering of our commits with priority on merged work vs local
 changes.

### Basic Assumptions

 We use two mandatory repositories / forks.

 * `origin` should point to your fork of the projectName/* repository
 * `upstream` should point to projectName/* for the project your are contributing to
  * `git remote add upstream <github url>`

### Fool Proof Rebase Strategy

Rebase is a powerful feature, and with great power comes great responsibility.

##### Keep your master up to date with upstream master

 * `git checkout master`
 * `git pull --rebase upstream master`

##### Keep your `feature/bugfix/refactor/format` branch up to date with the history from upstream

 * `git checkout <your-branch>`
 * `git rebase master`

##### That's it, you have now rebased and replayed your work to be AFTER the work of others.

Change the code, including various git commits.

##### Now, to squash the commits.
 
 `git rebase -i master`

##### Then to push and replace any prior pushed commits.

WARNING: do not at any time perform either of these on anyone else's branch.  Definitely do not
do force commits to a master branch.  If new to git, ask for assistance first.

 `git push origin +<your-branch>`

 Or:

 `git push -f origin <your-branch>:<your-branch>`

 Now you have shared your new version of history with your copy of the repository. Please
 note that force pushing `-f` flag to a remote is very dangerous if you are sharing
 your copy of the history. Only do this on branches you are working on by yourself.

 It is under no circumstance ever appropriate to force push to the `master` branch

### Feature Branches

When starting some new work on  your fork, always commit to a branch with one of the
following formats for naming purposes

* `feature-*`: you are adding a new feature to our codebase
* `refactor-*`: you are trying to change or actually refactor (writing tests) existing code
* `bugfix-*`: you are trying to fix a bug in existing code
* `format-*`: you are simply reformatting to match team standards - no changes made at all

Always submit your PRs from one of the above branches, never submit PRs from master

    ### Pull Requests

    Every pull request (PR) submitted via GitHub needs to include the following details:

    #### Change Summary

    A human-digestable summary of the semantics changes your branch introduces to the code base.

    #### Tests

    The output of unit tests run against relevant files in your commit, as well as any notes on other tests you may have performed manually.

    #### Release Notes

    Additional requirements, if any, needed to deploy your change.


The purpose here is to provide context to the review that might not be readily apparent by
looking at the code itself; to provide an audit trail of changes that might be used to generate
a change summary during a software release cycle; to demonstrate that you have tested the changes, and to present the results of those changes; and to inform anybody deploying the change as to
other steps that may need to be performed in order for the change to work (perhaps installing a new npm module, updating the database schema, or ensuring another PR is release in tandem with the
one you've submitted).