I'm using this model in a team of 12, it works fine, except for: 1. needing to have reliable testing environments for QA/product people to try features, as many feature branches are worked on at once; and 2. new people having trouble with rebasing, or have to understand git just a little bit better than pull/push/commit.
> 1. needing to have reliable testing environments for QA/product people to try features, as many feature branches are worked on at once
Makes sense. Also, try using continuous integration (which should test every commit), and try teaching people to check out particular commits (by hash). I find that once people understand what "headless" means, and how to get out of it, `git checkout <commit hash>` is a very useful way to test _specific_ things.
> 2. new people having trouble with rebasing, or have to understand git just a little bit better than pull/push/commit.
I think the lesson here is that spending a bit of extra time teaching your developers (not to panic,) how git works, and how more obscure commands work, goes a long way.
