[OH-Dev] Re-choosing a git workflow (i.e., thoughts on "git flow")

[Asheesh Laroia]

Hey all,

A bit over a month ago, we agreed to try using the workflow described 
here: http://nvie.com/posts/a-successful-git-branching-model/

I wanted to share my thoughts, make a proposal, and ask what people think.

Having used it for more than a month, here are my thoughts:

* I really like "git merge --no-ff". I really like retaining the identity 
of a branch when it lands. It motivates me to keep my changes separated 
because the separation is retained when the branch lands. It also solves a 
real problem I have encountered, which is that if I need to understand 
change history to e.g. revert things quickly, it has been hard to identify 
what a previous probably-good commit was.

This way, history looks like:


*---------*------------*
|        / \          / 
*---*---*   *--*---*-*

The top row indicates only when branches were landed.

* However, "git flow" is not a perfect match for us. We do deployments 
more often than we do "releases". We could make the "develop" branch be 
live, but then what is master even *for*?

* (It might yield the following question from contributors: "Which branch 
should I work on top of -- develop, or master?")

* Jessica McKellar points out that the deployment system should be able to 
mark a commit as "live", and suggests that it do so by making a branch 
name called "live" point at the commit that is live. Thumbs up from me.

* Branches are good for letting people collaborate, and better than 
sending patches around; for example, I've enjoyed pushing commits to 
origin/front_page_demo.

So here is what I suggest, given my experience:

* When we land a patch or branch into the main branch for deploying, we 
(1) first rebase it to be against origin/master, then (2) use "git merge 
--no-ff" so that people can still see the branch's history.

* We ask people to avoid rebasing publicly-visible branches until they're 
ready for submission. This makes collaboration easier.

* This way, people can easily work off OpenHatch git repo forks on Github, 
Gitorious, and their own private repositories (e.g. how Jack Grigg kept 
and published his own repo). It puts us in a good position to accept merge 
requests via the Gitorious UI and the Github UI.

* We start using the branch namee "live" to label the commit that is 
currently live on the site.

* We avoid using merge except for commits that could be a fast-forward.

What do people think?

-- Asheesh.