Write [short] chapter on MoFo implementation of git-flow.

[simonwex]

http://nvie.com/posts/a-successful-git-branching-model/

[alicoding]

It might be easy to adopt this sooner since we just started working on this repo?

@toolness @simonwex @jbuck @gesa @mmmavis ?

[mmmavis]

agree, let's create a develop branch and make that the default branch on https://github.com/mozilla/teach.webmaker.org.

[gesa]

On it

[gesa]

Done. develop is now the default branch on teach, let's all make sure to branch and PR off that.

[mmmavis]

:dancers: okie dokie

[alicoding]

Let's also create a gh-pages where we can check our stuff every time we tag on production. I think we can automate this by running something like 'gulp prod' which should tag things to master branch and push dist directory to gh-pages

[toolness]

Hey out of curiosity, have we ever considered GitHub Flow?

http://scottchacon.com/2011/08/31/github-flow.html

[simonwex]

The biggest implications that Github flow would have on us are:

1) anything in the master branch is deployable

and

6) deploy immediately after review

Our current deployment strategy and our product strategy over the next few months doesn't fit with this, and hence our ability to do actual hotfixes is actually quite important.

This isn't true across all projects. I suspect that we could have an always-deployable master on id.webmaker.org and the Teach site. Production webmaker.org on the other hand will likely diverge from what we commonly see on our development branches. What would our flow look like to update the webmaker.org homepage?

[simonwex]

@jbuck from a devops perspective, changing our system so we don't require tags, but instead we deploy-on-merge is something is also something you'd need to do in order for us to embrace this simpler system.

I'll also say, if we can get there, Github Flow is more desirable and I generally agree with Scott Chacon.

[jbuck]

At Whistler we decided to not continue working on the handbook