Verify, test, and comment on the PR as needed

At this point you should:

Review all of the updates

Verify and test effected parts of the code

Check code style, and other standards

Work with the contributor through comments in the PR, IRC, forums, or whatever will accomplish the task. As the contributor makes updates work them until the PR is acceptable in quality and consistent with our coding standards.

Push updates to upstream

When satisfied with the quality and functionality of the PR you can push to the upstream repos. Remember you must make sure you are up to date with upstream, and rebase as needed as described above.

There are two options here for merging. You can use --ff-only to not keep the topic branch - this is fine for simple, or single commit updates. For complex or multi-commit updates you can use --no-ff which will force a merge commit, and maintain the topic branch. This can make it easier to visualize, debug and bundle related commits.

At this point the upstream repo, your fork, and your local repo's should be in sync and have the commits from the PR in place.

Wrapping up

The final steps are:

Close the PR

GitHub may do this for you automatically based on the push

Resolve the jira

Resolve the associated jira

Thank the user, and offer to buy them a beer the next time we meet!

Handling your own pull request

This section describes addition steps you should take when handling your own pull request for the various reasons discussed above. They are exactly the same and the instructions above, except as described outlined below.

Test it again

Your going to be committing code that has had only one set of eyes on it. Run through a couple of extra tests, verify the wording, etc...

Comment in the PR

Add a comment in the PR describing why you needed to push this PR yourself. If other project developers "+1"'ed this is not needed.