Discuss and document Steve's approach to orchestrating with upstream

[allspiritseve]

cc @scouttyg @JangoSteve

In a nutshell:

master: tracking upstream. Does not contain customizations or features that have not been pulled in to upstream yet.
aj: deployable branch, frequently rebased against master (so our commits are always on top of upstream)
feature branches: develop customizations with potential to be merged back upstream. Might be used for upstream pull requests, or merged into aj.

This is close to how I organized my local repo when attempting to merge in upstream. The biggest difference was that I had an upstream branch (equivalent to Steve's master) and my master was equivalent to Steve's aj.

I still kind of like master being our deployable version. That's the first branch that comes up by default, so if we were to write an informative README about how we orchestrate upstream and customizations, that would show up instead of Errbit's README.

What do you guys think?

[JangoSteve]

I'd still like aj to be the deployable branch and for master to track the remote repo. Considering the accepted way to do pull requests is through a separate topic-branch, it makes more sense to me for all our customizations to the actual project to also be on a topic branch.

I think a better solution for displaying our stuff by default in Github, is to simply change the default branch in our fork to aj in the settings.