How to Handle AeroGear Pull Requests

This article shows the guidelines and tasks required for project developers to manage and handle pull requests (PR).

General Guidelines

These are general guidlines about handling PRs and things to keep in mind as a project developer.

 

  • All changes should be made via PRs
  • You should not process your own PRs
    • Another project developer should handle your PR as described below
      • This is especially important for large or complex changes
    • Exceptions:
      • Updates are clearly trivial
      • No one is available to review in a timely manor
      • Updates are blocking your progress with other critical items
      • Another project developer has "+1"'ed the PR after a basic review
  • Do NOT use the GitHub PR merge facilities
    • This creates merge commits that we want to avoid

Handling a Pull Request

This section talks about handling a pull request generated from a community member or another project developer.

 

Add a git remote reference to the PR location

You will need to get the updates from the contributors repository into your own.  To do this create a remote reference to their repo

 

git remote add contrib_usr git@github.com:[contrib_usr]/[target repo].git

Create a topic branch and pull in PR updates

It is highly recommended that you create a topic branch for verifying PRs.  After that you need to pull in their updates for review.

 

git checkout -b pr_topic_branch
git fetch contrib_usr
git rebase -i contrib_usr/<contrib_topic_branch>

 

You now have a topic branch that should be the exact same as the PR.

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

 

git checkout master 
git merge --ff-only pr_topic_branch
git push upstream
git push origin 
git branch -d pr_topic_branch

 

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.