This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Choose the best response for each question.
What is not a good reason to create a pull request?
You would like to receive feedback on prospective changes before merging your feature branch into main.
main
You want to merge your bug fix branch into main, but don't have permission.
Your branch can't be merged into main due to upstream changes made since you created it. Creating a pull request lets the other contributor know they need to pull their changes out so you can put yours in.
How can you ensure that pull requests for a given area of the repository, aren't merged unless certain users or teams approve?
Clearly explain the pull request policy in CONTRIBUTING.md.
Use a CODEOWNERS file and enable required reviews.
Add a table that maps directory paths to required users in SECURITY.md.
You're requested to review a pull request. As you read through it, you notice several minor coding errors and typos. How should you handle the review?
Start a review and fix obvious typos inline. Add comments in places that require further discussion or offer educational value. Complete the review with changes requested.
Leave single comments for each issue you come across, but don't change the code. For typos, include the correct spelling of the word as a reference. Approve the pull request if you trust the author to implement your suggestions.
Reject the pull request. We can't risk any bugs accidentally being merged into an important branch.
You must answer all questions before checking your work.
Was this page helpful?