Git flow, patch and review process

mixedpuppy edited this page Jul 25, 2011 · 1 revision
Clone this wiki locally

Git branch management

  1. 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 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.
  1. 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.
  1. 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

  1. Every change or set of changes must correspond to a bug. If there isn't a bug yet, file one in the appropriate component:
  1. 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).

How to submit changes for review

  1. Before you submit your work for review, ensure your bug/123456-short-bug-description branch merges without conflicts!
  2. 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).
  3. 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 :philikon
  4. 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.

How to review and land

  1. The reviewer can comment on the pull request.
  2. Once the work is accepted, the reviewer sets r+ in bugzilla.
  3. 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
  1. Paste a link to the merge changeset into the corresponding bug and mark the bug as RESOLVED FIXED.
  2. 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

Who can review?

  • f1
    • mixedpuppy
    • mhammond
  • ...

Review guidelines

  • Ensure code adheres to relevant coding style:
  • All changes need appropriate test coverage (you touch it, you own it!)