[owenversteeg]

I disagree with "Keep the master branch deployable at all times." Both my CSS framework Min (http://minfwk.com) and several other popular GitHub projects use the strategy of 'only use one branch, and use tags to mark stable versions'.

Min's only branch (gh-pages, so we can serve the site with GitHub) is usually "unstable" (in the sense that a CSS framework can be unstable.) If someone wants a stable release, that's what Git's tag system is for.

[awj]

I think the idea is sound, but the reasoning isn't. Keeping master deployable at all times forces breaking changes off into feature branches so unrelated pieces of functionality can't interfere with each other's release schedules.

Keeping master deployable for bug fixes doesn't make sense to me, though. Are you going to deploy new features sitting in master because something else had a bug? Just go look up the last release tag, make your bug fixes there, then merge them into master.

I've been bitten too many times by unstable features holding up releases on master (both my features and other team member's). Feature branches do a wonderful job of solving this and the required merge back into master gives you a nudge to prevent scope creep.