The existing workflow suggests using error prone commands such
as `git rebase`. This workflow avoids such commands and tries
to infuse other best practices.

- Add a horizontal rule before details section
- Add bold to note at the top
- Remove meta comment at the top

- Remove squash since this can be done by the maintainer
  when accepting a pull-request.
- Move multi-round before conflict since it is easier
  and gives participants a chance to practice the basic
  workflow before having to deal with a conflict.
- Minor renames in contributor.md.

Push changes is used during work and during cleanup. We're on different branches in each case (feature and master). Rather than specifying each explicitly (`git push origin master` and `git push origin FEATURE_BRANCH`) or asking folks to figure out which branch needs pushing (`git push origin BRANCH_THAT_NEEDS_PUSHING`), we will have them push up all branches with `git push`. It is usually considered best practice not to push all branches in case you are midway through a change in a branch that you don't want pushed. But at this stage, it overcomplicates things.

I changed my mind from the last commit. Rather than use `git push`, wanting to use the best practice of specifying the remote and branch in a push, and believing that students will learn parallel forms faster than variations, I have made two recipes for push: one for pushing the feature branch, and one for pushing master.

The goal is to synchronize master with our repositories. So we need to push to origin after pulling from upstream.

For consistency.

From burged

The formation of teams was already a bullet item in the README -- maybe pull that bulleted item from the README -- it makes more sense for the formation of teams to be here.

Closes #30

Closes #29

Closes #32

Closes #33

Related to #34

Related to #34

related to #34

Related to #34