pull-requests

Subscribe to all “pull-requests” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

A CODEOWNERS file defines the users or teams responsible for different parts of your repository, and helps ensure the right people are included in pull request reviews. We've shipped some improvements that make it easier to work with CODEOWNERS!

Surfacing syntax errors

Syntax errors are now surfaced when viewing a CODEOWNERS file from the web. Previously, when a line in a CODEOWNERS file had a syntax error, it would be ignored or in some cases cause the entire CODEOWNERS file to not load.

Screenshot of a CODEOWNERS file with errors

GitHub Apps and Actions can access the same list of errors using new REST and GraphQL APIs.

See which CODEOWNERS will be requested for review

When creating a new pull request or after pushing new changes to a draft pull request, any CODEOWNERS that will be requested for review are now listed:

Screenshot of pending reviewers on a draft PR

This gives you an early look at who will be requested to review once the pull request is marked ready for review.

Comment on the same line

Comments in CODEOWNERS files can now appear at the end of a line, not just on their own line:

*.js    @js-owner       # All JavaSript files

Learn more about CODEOWNERS files.

See more

GitHub can display several common image formats, including PNG, JPG, GIF, PSD, and SVG, and provides several ways to compare differences between versions. Now when reviewing added or changed images in a pull request, previews of those images are shown by default:

image

Previously, you would see a message indicating that binary files could not be shown and you would need to toggle the "Display rich diff" option.

Learn more about working with non-code files.

See more

The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch. This is useful for verifying your changes are compatible with the current version of the base branch before you merge. Two enhancements now give you more ways to keep your branch up-to-date.

Update your pull request branch by rebasing

When your pull request's branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch. Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created.

To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch.

Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice.

Note: Because rebasing rewrites the history of the branch, if you are working with the branch locally, you will need to fetch it and do a hard reset to ensure your local branch matches the branch on GitHub.com.

Learn more about keeping your pull request in sync with the base branch.

Always have the option to update

A new repository setting lets admins opt into having the Update branch button always available whenever a pull request's branch is not up to date with the base branch. Previously, this button was only available when the Require branches to be up to date before merging branch protection setting was enabled.

Repository admins and maintainers can manage the Always suggest updating pull request branches setting from the Pull Requests section in repository settings.

Always suggest updating PR branch repo setting

Learn more about managing suggestions to update pull request branches.

See more

We have introduced a new policy setting that controls whether GitHub Actions can approve pull requests. This protects against a user using Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user.

To prevent breaking existing workflows Allow GitHub Actions reviews to count towards required approval is enabled by default. However, an organization admin can disable it under the organization's Actions settings.

image

See more

You can now control which GitHub App a required status check is provided by. If status is then provided by a different app or by a user via a commit status, merging will be prevented. This ensures all changes are validated by the intended app.

Screenshot of a repository's required status check settings, specifying which GitHub App is required for each status check

Existing required status checks will continue to accept status from any app, but can be updated to only accept status from a specific app (see Editing a branch protection rule). Newly-added required status checks will default to the app that most recently reported the status, but you can choose a different app or allow any app to provide the status.

For more information see our documentation about protected branches.

See more

Administrators can now allow specific users and teams to bypass pull request requirements.

For context, this image shows how administrators can use branch protections to require pull requests for all changes to a branch:

screenshot of option to protect matching branches

This is a good practice, but you may want to make exceptions to this rule for specific people and teams. For example, if you have an automated process that calls GitHub APIs to make changes in a repository, you may want to permit that automation to make changes without creating a pull request.

Now, when you require pull requests and their related protections for a branch, you can specify people and teams who should be free from those requirements. As shown in the image below, select Allow specific actors to bypass pull request requirements. Then, search for and select the people and teams who should be allowed to bypass the requirements.

Screenshot of option to bypass PR requirements

For more information, visit Managing a branch protection rule.

See more

The "Only notify requested team members" setting can now be enabled independently of "Enable auto assignment" in the Team's code review settings.

This is useful in scenarios where many users are auto assigned but not all users require notification. For example, when repositories are configured with teams as code owners but contributors know the specific individual to review their pull request. This setting now allows you to require that team for review, but without always notifying the whole team unnecessarily.

Read more about managing code review settings for your team.

See more

You can now require that all changes to a protected branch are made using a pull request, but without requiring reviews. This can be useful when you want to use pull requests for tracking purposes or to simplify your continuous integration (CI) configuration, but don't want to gate merging on review.

Previously, you could create a branch protection rule that required pull requests with approving reviews before commits could be merged into a branch. When pull requests were required, approving reviews were also required. This didn’t meet the needs of users who wanted to require pull requests for tracking purposes or CI validation, but who didn’t want their ability to merge to be gated by approving reviews.

Now, requiring pull requests and requiring approving reviews are separate options of protecting a branch. For example, you can now require pull requests without requiring reviews, or with requiring approving reviews. This flexibility lets you choose what is best for you and your branches.

image

For more information, visit Managing a branch protection rule.

See more

Pull Request Merge Queue is now available in limited beta. Learn more about the feature and how to request early access.

Why a merge queue?

Maintaining high velocity and keeping your main branch green can be a challenge today. Many repositories try to do this by requiring all pull requests be up to date with the main branch before merging. This ensures the main branch is never updated to a commit that has not passed all required status checks, but forces developers to update (or rebase) their pull request branches multiple times and then wait for status checks to complete before trying to merge again. On some projects, status checks can take 30 or more minutes and if another pull request gets merged during this time, the process starts over (for everyone). This can have a significant impact on the overall velocity of the team and make it harder for developers to move onto their next task.

Merge Queue provides the benefits of requiring pull request branches to be up to date before merging, but without requiring developers to go through this process.

How it works

Merge Queue works by validating different combinations of pull requests identified as “ready to merge” in parallel so that pull requests can merge efficiently and without the typical delays that exist between merges today.

GIF of merge queue demo

Once a pull request has been approved and has passed all required status checks, a user with write access in the repository can queue the pull request to be merged. The pull request branch does not need to be up to date with the base branch before being queued. The merge queue then creates a temporary branch that includes the pull request and any non-failing pull requests ahead of it in the queue. This branch is based on the latest version of the base branch and is what the history of the base branch will look like if it passes all required status checks. Assuming it does pass these checks, the base branch is fast-forwarded and the pull request is marked as merged.

Early access

Merge Queue is currently available in limited beta. This gives us the opportunity to better understand your requirements as we improve the quality and capability of the feature. In the first phase of this beta, access to the feature is limited to a select number of organizations that meet certain requirements like having a consistently high volume of changes from multiple users being merged each day.

Organization admins can request early access for their organization by joining the waitlist: https://github.com/features/merge-queue/signup. You will need to provide the name of a repository in this organization that you plan on using merge queue on, but you will have the opportunity to test the feature on other repositories during the beta. We will contact you prior to onboarding to work through the details.

Early access will expand to more organizations over the coming months.

Learn more

For the latest updates on this feature, see the public roadmap issue and #merge-queue posts in the GitHub Changelog.

To learn more about configuring and using the feature once it is available to you, start with “Adding a pull request to the merge queue“.

See more

You can now choose to use a fixed-width font in Markdown-enabled fields, like issue comments and pull request descriptions. Currently these fields use a variable-width font, which can make it difficult to edit advanced Markdown structures like tables and code snippets.

To enable, go to your appearance settings and toggle on Use a fixed-width (monospace) font when editing Markdown in the “Markdown editor font preference” section.

fixed-width-font

Learn more about writing and formatting on GitHub.

See more

Announcing new settings to help teams manage code review assignments. Also improved pull request filtering that lets you see just the pull requests you have been directly requested to review.

New ways to manage code review assignment

Code review assignment helps distribute a team's pull request review across the team members so reviews aren't the responsibility of just one or two team members. New settings give teams more control over the behavior:

  • Limit assignment to only direct members of the team. Previously, team review requests could be assigned to direct members of the team or members of child teams.

  • Continue with automatic assignment even if one or more members of the team are already requested. Previously, a team member who was already requested would be counted as one of the team's automatic review requests.

  • Keep a team assigned to review even if one or more members is newly assigned. Previously, the team review request was always replaced by one or more individual review requests. This would make it difficult to find pull requests where a specific team was requested.

Code review assignments settings can be managed under Team settings > Code review assignment:

image

Better indication when a review request is assigned to a team member

The timeline and reviewers sidebar on the pull request page now indicate if a review request was automatically assigned to one or more team members (because the team uses code review assignment):

image

review assignment

This avoids some of the mystery that previously existed around automatic code review assignments, including whether a user was directly requested to review or the request was assigned.

Discovering just the pull requests you are requested to review

Regardless of whether your team uses code review assignment, you can now filter pull request searches to only include those you are directly requested to review (Awaiting review from you):

image

Previously, you could filter to see your review requests, but this list would include pull requests you or any team you are a member of was requested on. You can still see this list by filtering on Awaiting review from you or your team.


Learn more about pull requests, code review assignment, and searching pull requests.

See more

Filtered files on the Pull Request Files Changed tab are now completely hidden from view (not just collapsed). This helps decrease distractions and lets you focus on just the files you need to review:

improved file filter

The File Filter menu has also been simplified, but still supports the following filtering options:

Learn more about reviewing proposed changes in a pull request.

See more

Maintainers can now manage the repository-level "Allow auto-merge" setting. This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository. Previously, only admins could manage this setting.

Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs.

Learn more about managing auto-merge for pull requests in your repository.

See more

The new Required Conversation resolution branch protection rule and Conversations menu is now generally available. Easily discover your pull request comments from the files changed tab and require that all your pull request conversations are resolved before merging.

conversations-menu

You can enable and disable the conversation resolution branch protection rule through your repository branch settings, or with our REST and GraphQL APIs. Apart from this change, we are also introducing a new type of webhook event that is triggered when a conversation is resolved or unresolved.

Learn more about discovering and navigating conversations.

See more

On GitHub today, half of all pull request review conversations are left unresolved prior to merging. Now it is easier for authors to discover unresolved comments from the conversations menu in the files changed tab.

image

In addition to making it easier for you to discover conversations in your pull requests, a new branch protection option gives admins the ability to require all review conversations be resolved before the pull request can be merged. This helps ensure all review conversations are seen and addressed prior to merging.

image

Both features are currently in beta. Let us know what you think: give feedback.

See more

We are shipping improvements to pull request workflows on GitHub Mobile, making reviewing and merging pull requests much easier on the go!

  • The pull request description has been moved into the header, providing quick context about the changes without having to scroll to the timeline. Longer descriptions are truncated and can be expanded inline with a tap.
  • We brought the merge box designs more closely in line with GitHub.com. By using clear colors and iconography, it is easier to scan through the overall status of a pull request to understand the current state of reviews, checks, and overall mergeability.
  • We added a contextual call to action in the Files Changed cell that will help people understand when their review is required, or when new changes have been pushed to the pull request since their last review.
  • When reviews and checks are passing, pull requests can be merged directly from the view without having to open new dialogs. We've also built a fun animation that plays during a merge which will make working on the go feel more satisfying!


Read more about GitHub Mobile and send us your feedback to help us improve.

See more