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

Allow bypassing required pull requests

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

Team member pull request review notifications can be configured independently of auto assignment

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

Require pull requests without requiring reviews

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 Limited Beta

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

Fixed-width font support in Markdown-enabled fields

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

New code review assignment settings and team filtering improvements

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

Improved pull request file filtering

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 availability of auto-merge in a repository

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

New tools to discover and resolve pull request conversations now generally available

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

New tools to discover and resolve pull request conversations (beta)

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

Working with pull requests on GitHub Mobile is now much easier

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

Pull request events now included in the audit log

Pull request and review-related events are now included in the audit log at both the enterprise and organization levels. This helps administrators better monitor pull request activity and ensure security and compliance requirements are being met.

Events now included in the audit log:

  • A pull request is created, merged, closed, reopened, converted to draft, or marked ready for review
  • A review is requested or a request is removed
  • A review comment is added, updated, or deleted
  • A review is submitted, dismissed, or deleted

Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events. For example action:pull_request filters for events directly on a pull request, action:pull_request.merge shows just merge events, and action:pull_request_review shows review events.

Learn more about audit log and available pull request actions

See more
View more changes