This guide will walk you through the process of creating, reviewing, and approving pull requests (PRs). It covers the following topics:
This section is designed to help early career engineers or outside contributors when creating their first couple of PRs while developing for your project.
Suggested branch naming convention: initials/description
Example: "aa/replace-button-title"
As an engineering convention, name the PR with the team the change is associated with and a short but precise description of the change because once merged, this is typically how the commit gets its message, making it easier for anyone to broadly understand what area of impact a commit has when scanning commit history.
Example: "batches: create batch change form"
Apply applicable team label to the PR so that the associated team can easily find and identify PRs at a glance.
Example: "team/batchers"
If the PR is a result of a related GitHub issue, include “Closes #12345” in the PR’s description in order to auto-close the related issue once the PR is merged. This will also link the ticket and the PR together so that if anyone looks at either in the future, they won’t have any issue trying to find the corresponding ticket/PR as it will be noted in the sidebar.
Defer merging a PR until at least one person has approved of the changes.
Suggested but not required:
Further reading:
To create a PR that is easy to review and fosters a positive collaboration with your code reviewer, follow these guidelines: