GitHub and Mozilla Work Process

Nicholas Zakas sent out a call to Twitter asking developers who use GitHub as a primary CVS to share their working process.  Mozilla uses GitHub for many (if not most, but I can't confirm that) mission critical web applications so I chimed in on how the Mozilla Developer Network team uses GitHub.  I got many questions about the process from different sources so I thought I would document our process here.

Working Setup

The working process starts with each developer cloning Mozilla's kuma repository.  The kuma repository includes developer instructions for getting setup with vagrant (recommended) or without.  Kuma is a Python/Django app with a MySQL database backend.  The kuma repository doesn't include all of MDN's documentation but that can be provided to developers who ask for it.  The MDN team resides in the #mdn IRC room for questions and planning.  Filed bugs for MDN can be found on Bugzilla.  This information is all you need to know to get started.

Working on Bugs/Enhancements

Let's say you're set up and it's time to work on a bug or enhancement.  The first step is to create a separate feature branch for working on the bug:

# Ensure we're on master
git checkout master

# Create and check out feature branch
git checkout -b bug-title-123456

Putting the bug number in the branch name is especially useful if there are long periods between working on the bug.  With the branch created and checked out, make your updates, additions, and removals.  It's also important to run tests as you work on the bug.

Submitting Pull Requests

Before submitting a pull request, it's important to squash commits and rebase on master branch:

# Ensure master is up to date with Mozilla's remote
git checkout master
git pull mozilla master

# Go back to feature branch, squash commits
git checkout bug-title-123456
git merge master
git rebase -i master
git push origin bug-123456

(Note:  I'm not a git legend so there's a good possibility I'm taking the long route to accomplish this task -- if so, let me know)

The code above turns all commits into one commit, so it's easier to back out if necessary.  We also start commit messages with "fix bug {bug number}" -- this allows out post-merge hook to automatically RESOLVED:FIXED the bug in Bugzilla.  If all looks good, submit the pull request via GitHub.

PR and Code Review

Upon submission of the pull request, the code is automatically run through Mozilla's Jenkins test suite.  If the tests pass, the pull request is technically able to be merged.  At this point, however, a different member or members of the team review the submitted code, making comments on possible improvements or problems that may be come up along the way.  If the submitter needs to make more changes, they should make their commits, squash and rebase again, and push:

git push -f

So that's the MDN team's process for managing code on GitHub.  It all seems pretty standard and straight-forward but let me know if you have suggestions or questions.  I like the way things work and the rest of the team seems to as well!