Git flow, patch and review process
Clone this wiki locally
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.
developbecomes the default branch,
masteris 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.
How to make changes
- 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
123456is the bug number and include a short description of the bug so
git branchoutput 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).
How to submit changes for review
- Before you submit your work for review, ensure your
bug/123456-short-bug-descriptionbranch merges without conflicts!
- To ask for review, create a GitHub pull request from your
bug/123456-short-bug-descriptionbranch to the
developbranch (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-descriptionbranch, obsolete the previous pull request (incl. the corresponding file in bugzilla) and repeat these steps.
How to review and land
- 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
developwith 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)
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-descriptionbranch locally and from GitHub:
git branch -d bug/123456-short-bug-description git push origin :bug/123456-short-bug-description
Who can review?