Git flow, patch, and review process

Git branch management

Projects that need to interact should follow a common practice for branch, fix and release management. The process we will follow, with some modification, is described at nvie.com. The gitflow project has tools to manage this process.

develop becomes the default branch, master is the stable releases branch.
in place of feature/name branches we will generally use bug/# branches to tie the branch to a bugzilla bug entry. The gitflow tools allow you specify 'bug/' as the default branch prefix.

Starting from an existing git repo that has used master for development, you can switch the default branch by doing:

git checkout -b develop master
git push origin develop
in github, go to the projects admin page and change the default branch. This will cause new clones to get 'develop' as the default.

new git repos can benefit from being initialized with gitflow, but you still have to update github. The manual steps are basically the same as above.

Every change or set of changes must correspond to a bug. If there isn't a bug yet, file one in the appropriate component
Create a branch for your bug called bug/123456-short-bug-description where 123456 is the bug number and include a short description of the bug so git branch output makes sense to the casual observer. Commit your changes to that branch.

Changes to the develop branch that haven't been reviewed will be backed out (modulo trivial stuff like whitespace fixes or typos in documentation).

Before you submit your work for review, ensure your bug/123456-short-bug-description branch merges without conflicts!
To ask for review, create a GitHub pull request from your bug/123456-short-bug-description branch to the develop branch (Warning: the GitHub pull request interface has the base branch on the left).
Attach a dummy file to the bug that points to the GitHub pull request and request review. You can use Dietrich's GitHub + Bugzilla JetPack to do this at a button's push. Alternatively, Atul Varma's bzpatch tool from philikon's pybugzilla repository also automates this nicely: bzpatch pullreq 123456-short-bug-description https://github.com/mozilla/client-share-web/pull/49 :philikon
If the reviewer has follow-up comments, continue to work in the bug/123456-short-bug-description branch, obsolete the previous pull request (incl. the corresponding file in bugzilla) and repeat these steps.

The reviewer can comment on the pull request.
Once the work is accepted, the reviewer sets r+ in bugzilla.
Given r+, either the original author or the reviewer merges the bug/123456-short-bug-description branch to develop with these options:

an explicit merge commit (no fast fowarding)
an explicit log message according to the Mozilla conventions (copy the bug number and bug title from Bugzilla and append r=reviewer) Example: git merge --no-ff -m "Bug 123456 - Frobnicate the blerghmark into the pabblargh. r=somebody" bug/123456-short-bug-description

Paste a link to the merge changeset into the corresponding bug and mark the bug as RESOLVED FIXED.
Remove the bug/123456-short-bug-description branch locally and from GitHub:

     git branch -d bug/123456-short-bug-description
     git push origin :bug/123456-short-bug-description

Ensure code adheres to relevant coding style:
- add-on: Mozilla coding style
- web: same as above plus modern cross-browser compliance and JSLint compliance
- server: PEP8
All changes need appropriate test coverage (you touch it, you own it!)