Skip to content

Commit 9fff1da

Browse files
authored
Merge pull request #35591 from github/repo-sync
Repo sync
2 parents 0a9b458 + 707d0ac commit 9fff1da

File tree

4 files changed

+94
-38
lines changed

4 files changed

+94
-38
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
---
2+
title: Helping others review your changes
3+
intro: 'You can use pull requests to provide clear context for your changes and keep your team informed, improving collaboration and the quality of reviews.'
4+
redirect_from:
5+
- /pull-requests/collaborating-with-pull-requests/getting-started/best-practices-for-pull-requests
6+
versions:
7+
fpt: '*'
8+
ghes: '*'
9+
ghec: '*'
10+
topics:
11+
- Pull requests
12+
shortTitle: Help others review your changes
13+
---
14+
15+
When you create a pull request, you’re asking your team to review your changes and provide feedback. This guide provides best practices for creating pull requests that are easy to review and keep your team informed, so that you can improve collaboration and the quality of reviews.
16+
17+
## Making your changes easy to review
18+
19+
Clear context in your pull requests helps reviewers quickly see what you’ve changed and why it matters. This makes the review process faster and smoother, with less back-and-forth, and helps your team give better feedback and make confident decisions. For information on creating a pull request, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)."
20+
21+
### Write small PRs
22+
23+
Aim to create small, focused pull requests that fulfill a single purpose. Smaller pull requests are easier and faster to review and merge, leave less room to introduce bugs, and provide a clearer history of changes.
24+
25+
### Review your own pull request first
26+
27+
Review, build, and test your own pull request before submitting it. This will allow you to catch errors or typos that you may have missed, before others start reviewing.
28+
29+
### Provide context and guidance
30+
31+
Write clear titles and descriptions for your pull requests so that reviewers can quickly understand what the pull request does. In the pull request body, include:
32+
33+
* The purpose of the pull request
34+
* An overview of what changed
35+
* Links to any additional context such as tracking issues or previous conversations
36+
37+
To help reviewers, share the type of feedback you need. For example, do you need a quick look or a deeper critique?{% ifversion copilot %} Additionally, you can use {% data variables.product.prodname_copilot %} to generate a summary of your pull request. See "[Use {% data variables.product.prodname_copilot %} to generate pull request summaries](#use-github-copilot-to-generate-pull-request-summaries)," later in this article.{% endif %}
38+
39+
If your pull request consists of changes to multiple files, provide guidance to reviewers about the order in which to review the files. Recommend where to start and how to proceed with the review.
40+
41+
## Keeping your team informed
42+
43+
Pull requests can do more than just document code changes—they’re also a powerful way to keep your team and manager informed about the status of your work. By making your progress visible in your pull requests, you can reduce the need for separate updates and ensure everyone stays aligned.
44+
45+
{% ifversion copilot %}
46+
47+
### Use {% data variables.product.prodname_copilot %} to generate pull request summaries
48+
49+
> [!NOTE] {% data reusables.copilot.copilot-requires-subscription %}
50+
51+
You can use {% data variables.product.prodname_copilot_short %} to generate a summary of a pull request on {% data variables.product.github %}. You can use the summary to help reviewers understand your changes.
52+
53+
1. On {% data variables.product.github %}, create a pull request or navigate to an existing pull request.
54+
55+
> [!NOTE] {% data variables.product.prodname_copilot %} does not take into account any existing content in the pull request description, so it is best to start with a blank description.
56+
57+
1. Navigate to the text field where you want to add the pull request summary.
58+
59+
* If you're creating a new pull request, use the "Add a description" field.
60+
* If you're adding a description to an existing pull request, edit the opening comment.
61+
* If you're adding a summary as a comment, navigate to the "Add a comment" section at the bottom of the pull request page.
62+
63+
1. In the header of the text field, select {% octicon "copilot" aria-label="Copilot actions" %}, then click **Summary**.
64+
65+
![Screenshot of the form for creating a pull request. A Copilot icon is highlighted, and a box appears with the "Summary" command.](/assets/images/help/copilot/copilot-description-suggestion.png)
66+
67+
1. Wait for {% data variables.product.prodname_copilot %} to produce the summary, then check over the results carefully.
68+
1. Add any additional context that will help people viewing your pull request.
69+
1. When you're happy with the description, click **Create pull request** on a new pull request, or **Update comment** if you're editing an existing description.
70+
71+
{% endif %}
72+
73+
### Link to related issues or projects
74+
75+
Connect your pull request to relevant issues or project boards to show how your work fits into the larger project.
76+
77+
* Add keywords like `Closes ISSUE-LINK` in your description to automatically link and close the issue when the pull request is merged.
78+
* Use {% data variables.product.prodname_projects_v2 %} to track your work and link to the project from your pull request, making progress easy to track in one place. See "[AUTOTITLE](/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects)."
79+
80+
### Highlight the status with labels
81+
82+
Add a status label to your pull request to show whether it’s ready for review, blocked, or in progress. This helps reviewers understand the state of your work at a glance. For more information, see "[AUTOTITLE](/issues/using-labels-and-milestones-to-track-work/managing-labels)."

content/pull-requests/collaborating-with-pull-requests/getting-started/index.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,6 @@ topics:
1717
- Fundamentals
1818
children:
1919
- /about-collaborative-development-models
20-
- /best-practices-for-pull-requests
20+
- /helping-others-review-your-changes
21+
- /managing-and-standardizing-pull-requests
2122
---
22-

content/pull-requests/collaborating-with-pull-requests/getting-started/best-practices-for-pull-requests.md renamed to content/pull-requests/collaborating-with-pull-requests/getting-started/managing-and-standardizing-pull-requests.md

Lines changed: 9 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,72 +1,46 @@
11
---
2-
title: Best practices for pull requests
3-
intro: 'You can follow best practices to improve the consistency and quality of pull requests and pull request reviews.'
2+
title: Managing and standardizing pull requests
3+
intro: 'Use these steps to manage and standardize the pull requests that contributors create in your repository.'
44
versions:
55
fpt: '*'
66
ghes: '*'
77
ghec: '*'
88
topics:
99
- Pull requests
10-
shortTitle: Best practices
10+
shortTitle: Manage and standardize pull requests
1111
---
1212

13-
## Best practices for creating pull requests
13+
If you are a repository maintainer, there are several ways that you can manage and standardize the pull requests that contributors create in your repository. These steps can help you ensure that pull requests are reviewed by the right people, and that they meet your repository's standards.
1414

15-
When creating a pull request, follow a few best practices for a smoother review process. For information on creating a pull request, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)."
16-
17-
### Write small PRs
18-
19-
Aim to create small, focused pull requests that fulfill a single purpose. Smaller pull requests are easier and faster to review and merge, leave less room to introduce bugs, and provide a clearer history of changes.
20-
21-
### Review your own pull request first
22-
23-
Review, build, and test your own pull request before submitting it. This will allow you to catch errors or typos that you may have missed, before others start reviewing.
24-
25-
### Provide context and guidance
26-
27-
Write clear titles and descriptions for your pull requests so that reviewers can quickly understand what the pull request does. In the pull request body, include:
28-
29-
* The purpose of the pull request
30-
* An overview of what changed
31-
* Links to any additional context such as tracking issues or previous conversations
32-
33-
To help reviewers, share the type of feedback you need. For example, do you need a quick look or a deeper critique?
34-
35-
If your pull request consists of changes to multiple files, provide guidance to reviewers about the order in which to review the files. Recommend where to start and how to proceed with the review.
36-
37-
## Best practices for managing pull requests
38-
39-
If you are a repository maintainer, take these steps to manage and standardize the pull requests that contributors create in your repository.
40-
41-
### Use pull request templates
15+
## Using pull request templates
4216

4317
Pull request templates let you customize and standardize the information you'd like to be included when someone creates a pull request in your repository. When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body. For more information, see "[AUTOTITLE](/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository)."
4418

4519
You can use pull request templates to standardize the review process for your repository. For example, you can include a list of tasks that you would like authors to complete before merging their pull requests, by adding a task list to the template. For more information, see "[AUTOTITLE](/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists)."
4620

4721
You can request that contributors include an issue reference in their pull request body, so that merging the pull request will automatically close the issue. For more information, see "[AUTOTITLE](/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)."
4822

49-
### Define code owners
23+
## Defining code owners
5024

5125
You may want to make sure that specific individuals always review changes to certain code or files in your repository. For example, you may want a technical writer on your team to always review changes in the `docs` directory.
5226

5327
You can define individuals or teams that you consider responsible for code or files in a repository to be code owners. Code owners will automatically be requested for review when someone opens a pull request that modifies the files that they own. You can define code owners for specific types of files or directories, as well as for different branches in a repository. For more information, see "[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)."
5428

55-
### Use protected branches
29+
## Using protected branches
5630

5731
You can use protected branches to prevent pull requests from being merged into important branches, such as `main`, until certain conditions are met. For example, you can require passing CI tests or an approving review. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)."
5832

5933
{% ifversion push-rulesets %}
6034

61-
### Use push rulesets
35+
## Using push rulesets
6236

6337
{% data reusables.repositories.push-rulesets-overview %}
6438

6539
For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets#push-rulesets)."
6640

6741
{% endif %}
6842

69-
### Use automated tools to review code styling
43+
## Using automated tools to review code styling
7044

7145
Use automated tools, such as linters, in your repository's pull requests to maintain consistent styling and make code more understandable. Using automated tools to catch smaller problems like typos or styling leaves more time for reviewers to focus on the substance of a pull request.
7246

data/reusables/repositories/push-rulesets-overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,6 @@ Push rulesets allow you to:
1111
* **Restrict file extensions:** Prevent commits that include files with specified file extensions from being pushed.
1212
* **Restrict file size:** Prevent commits that exceed a specified file size limit from being pushed.
1313

14-
#### About push rulesets for forked repositories
14+
### About push rulesets for forked repositories
1515

1616
{% data reusables.repositories.rulesets-push-rulesets-fork-network-information %}

0 commit comments

Comments
 (0)