We're using a modified version of this successful git branching model to handle our releases. Main development happens in the 'master' branch. Production deploys come from the 'production' branch.
When we want to do a new release, we split off a new branch from master called release-X.Y.Z.
Xis the major version number -- currently 0, bumping up to 1 when we exit this beta period.Yis the release number -- this increments by one for every new release.Zis the hotfix number, which I'll describe later.
We deploy this release branch to a staging environment, where it can be QA'd. Any bugs discovered during this period can be fixed directly in the release branch. Once we're clear to go to production, we merge the release branch into production with the --no-ff option (to create a merge commit) and tag that merge commit with the release number. If any commits were added to the release branch, we need to merge them back into master, as well.
In the event that we need to deploy something to production immediately, we can create hotfix branch, named hotfix-X.Y.Z. These branches should be created off of the production branch rather than master. Once complete, these should be merged into production as well as master, unless there's an existing release branch, in which case merge into that instead of master.
git checkout production
git checkout -b hotfix-X.Y.Z
git add -A
git commit
git checkout production
git merge --no-ff hotfix-X.Y.Z
git tag -a X.Y.Z -m "Version X.Y.Z"
git push origin production
git push origin X.Y.Z
git checkout master
git merge --no-ff hotfix-X.Y.Z