Looks very sensible. We tend to not have a long running dev branch, and just cut features branches off master, similar to the 'how github uses github to build github' presentation [1].
Is anyone making squashing part of their workflow? We seem to prefer just plain merges with rebase.
Instead of squashing everything into a single master commit for each bugfix (which I've seen teams do), I use a merge commit to signify a set of commits that comprise a single feature or fix. (`git merge --no-ff`)
I make use of squashing when there is a clear group of commits that all change the same few lines of code or are conceptually part of the same incremental change. But then each incremental change (from working state to newer working state) I leave as a separate commit.
Is anyone making squashing part of their workflow? We seem to prefer just plain merges with rebase.
[1] http://zachholman.com/talk/how-github-uses-github-to-build-g...