Our model is a somewhat scaled-down version of how the Git project itself is run. We have two main branches
master: release quality
dev: integration branch for commits expected to go to master
In addition, we have:
'master' and 'dev' are stable; they will never be rewound or rebased. Feature branches are typically cut from 'dev', and usually rebased to 'dev' just before they are merged there. In the meantime they may be rebased or rewound as necessary. Being on 'dev' is not a guarantee that a commit will make it to master. Anything that turns out to not actually be ready will be reverted.
'dev' will always contain 'master'. Emergency fixes may go directly to 'master' which would then immediately be merged down into 'dev'.
As we get more contributors and start having "patch-churn", we will re-evaluate a three-branch model, like Git. The third branch would be 'pu' (for "proposed update").
We expect that people deploying the code will deploy from 'master' or from a release tag. We expect that people experimenting with the code will deploy from 'dev' or from their own feature branches or integration branches cut from 'dev'.