Skip to content

Instantly share code, notes, and snippets.

@gabebw

gabebw/how_to_pr.md

Created July 24, 2014 20:28
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gabebw/39adacfb03c7308644de to your computer and use it in GitHub Desktop.
Save gabebw/39adacfb03c7308644de to your computer and use it in GitHub Desktop.
Download ZIP
How to Read a Pull Request
Raw
how_to_pr.md

How to Read a Pull Request

  1. Go to the main pull request URL. It should end in /pull/NUMBER. Look at the 3 tabs right under the PR title. You should be in the "Conversation" view.

  2. Read the PR title and the PR description. The description should tell you what the developer is trying to accomplish in this PR. This gives you some mental structure so you know what you're looking at. It can also tell you what doesn't belong in this PR.

  3. Now click on the "Files Changed" tab and start looking at the code.

  4. First things first: Is the whitespace OK? Check indentation, check to make sure people have the right number of spaces before %>, make sure it's all 100% OK. If it's not, leave a comment!

  5. Now go back to the top and read the code. Read it carefully. Follow the path of the code. If you see a new controller action, look at its instance variables and look at the new view. Do they match up? Is the naming good? If YOU don't understand the naming, then it's not named well. Leave a comment!

  6. Is there something you don't understand? Leave a comment! "What is this doing?" or "I've never seen this before - can you give a quick overview?" is a great comment to leave. You'll learn something, and the developer who explains it to you will really understand it well once they explain it to you.

  7. When you're done commenting, a good comment to leave is "I'm done commenting for now" so people know to read their code. Usually developers will wait for people to finish reading their PR before they make changes, so that the PR doesn't change while people are looking at the code. Once the reviewers are done, the developer can make changes then send it back to the reviewers.

  8. Now go back through the cycle again.

  9. Once you don't have any more comments, leave a comment like "This looks ready to merge. 👍". (The emoji is optional.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment