We manage our branches in a similar manner to nvie’s branching model. The main difference is that we develop all code on the master branch and use the next branch as the place for staging releases.
New development happens on master, and is visible on https://preview.addons.mozilla.org. When we have a code freeze (every one or two weeks), the next branch is synced with master and is visible on https://next.addons.mozilla.org.
Tags should be created off of the next branch. If we need to release a hotfix, it should be applied to the next branch and tagged from there.
Most new code is developed in local one-off branches, usually encompassing one or two patches to fix a bug. Upstream doesn’t care how you do local development, but we don’t want to see a merge commit every time you merge a single patch from a branch. Merge commits make for a noisy history, which is not fun to look at and can make it difficult to cherry-pick hotfixes to a release branch. We do like to see merge commits when you’re committing a set of related patches from a feature branch. The rule of thumb is to rebase and use fast-forward merge for single patches or a branch of unrelated bug fixes, but to use a merge commit if you have multiple commits that form a cohesive unit.