Eventually you’ll get an r+. If you have commit access, now you can go ahead
and merge your branch. You may, if you want, rebase your branch to clean up
any embarrassing mistakes, but it isn’t required. If you don’t have commit
access the next part will be done by someone who does.

There are two options. The first is to press the Big Green Button in GitHub PRs
that says “Merge pull Request”. If you would prefer to do it manually (or
if there are merge conflicts, you can do this:

If you haven’t set up your local git user, please do before committing any code
for Kitsune. This way you can take credit for your work:

gitconfiguser.emailyour@github.emailgitconfiguser.name"Your Name"

The correct way to keep your local master up to date is:

gitcheckoutmastergitfetchmozillagitreset--hardmozilla/master

This will forcibly move your local master branch to whatever is on the Mozilla
master branch, destroying anything you have committed that wasn’t pushed.
Remember to always work on a branch that is not master!

Step one is to make sure there’s a bug in Bugzilla. Obvious “bugs” just need a
Bugzilla bug to track the work for all the involved teams. There are a number
of open bugs if you want to try your hand at fixing
something!

New features or changes to features need bugs to build a consensus of
developers, support team members, and community members, before we decide to
make the change. If you want to change something like this, be sure to file the
bug and get a consensus first. We’d hate to have you spend time on a patch we
can’t take.

To make sure no one else is working on the bug at the same time, assign it to
yourself in Bugzilla. If you have the proper permissions there’s an easy “take”
link next to the Assignee field. Ask in the IRC for details.

You can assign bugs to yourself even if you aren’t going to immediately work on
them (though make sure you will get to them sooner rather than later). Once you
are actively working on a bug, set the bug to the ASSIGNED state.

This describes the process for fixing a relatively small bug in a
single-commit. Large features may differ.

All bug fixes, changes, new features, etc, should be done on a “feature
branch”, which just means “any branch besides master.” You should make sure
your local master branch is up to date (see above) before starting a new
feature branch. Your feature branch should include the bug number in the branch
name, if applicable.

Once you have the bug fixed locally, you’ll need to push the changes up to
Github so you can open a pull request.

gitpush--set-upstreamoriginmy-feature-branch

Then, in your browser, navigate to
https://github.com/<yourname>/kitsune/compare/my-feature-branch and hit the
Pull Request button. If the commit message is clear, the form should be
filled out enough for you to submit it right away.

We add an r? in the pull request message indicating that this pull
request is ready to go and is looking for someone to review it.

Othertimes you may want to open a pull request early that isn’t quite ready to
merge. This is a great way to share the work that you are doing, and get early
feedback. Make it clear that your PR isn’t ready by putting [WIP] in the
title. Also make sure to say when it is ready! The best way to do this is to
remove [WIP] from the title and make a comment asking for r?.

It’s very rare that pull requests will be checked in immediately. Most of the
time they will go through one or more rounds of code review and clean-up.

Code review is usually comments made on the pull request or commits in Github,
asking for specific changes to be made. If the requested change isn’t clear, or
you disagree with it, feel free to ask questions inline. Isn’t Github’s
line-by-line commenting great?

Assuming a few small changes need to be made, make the changes locally on the
feature branch, then put them in a new commit. This makes it easier from
reviewers. For example, if Erik reviewed the pull request and asked for some
fixes, you might do this:

gitcheckoutmy-feature-branch# Make the changes.gitcommit-a-m"Feedback from Erik."gitpushoriginmy-feature-branch

Github will automatically add the new commit to the pull request, so we’ll see
it. Leaving it in a separate commit at this stage helps the reviewer see what
changes you’ve made.

There may be more than one round of feedback, especially for complex bugs. The
process is exactly the same after each round: make the changes, add them in yet
another new commit, push the changes.

There are also a few bots that might interact with your PR. In particular, our
continuous integration service will run tests and style checks on your new
code. All PRs must be approved by the CI system before they will be merged,
so watch out. They show up as either a red X or a green check mark in the
PR.

Once a pull request has gotten an r+ (“R-plus”, it’s from Bugzilla) it’s
ready to merge in. At this point you can rebase and squash any feedback/fixup
commits you want, but this isn’t required.

If you don’t have commit access, someone who does may do this for you, if they
have time. Alternatively, if you have commit access, you can press GitHub’s
“Merge pull request” button, which does a similar process to below. This is the
preferred way to merge PRs when there are no complications.