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:
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.
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.
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.
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.
Learn more about managing suggestions to update pull request branches.
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.
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.
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.
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:
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.
For more information, visit Managing a branch protection rule.
You can now quickly create a Markdown link in all Markdown-enabled fields, like issue comments and pull request descriptions, by pasting a URL on text that you have previously selected.
Learn more about writing and formatting on GitHub.
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.
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.
For more information, visit Managing a branch protection rule.
Pull Request Merge Queue is now available in limited beta. Learn more about the feature and how to request early access.
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.
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.
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.
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.
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“.
The diff setting to hide whitespace changes in the pull request Files Changed tab is now remembered for you for that pull request. You no longer need to re-enable it when you switch to another tab or when you come back to the same pull request later.
Learn more about reviewing proposed changes in a pull request.
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.
Learn more about writing and formatting on GitHub.
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.
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:
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):
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.
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):
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.
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:
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.
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.
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.
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.
With the latest version of Octicons, the states of an issue and pull request are now more visually distinct so you can scan status more easily.
Learn more about Primer, the GitHub design system.
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.
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.
Both features are currently in beta. Let us know what you think: give feedback.
We are shipping improvements to pull request workflows on GitHub Mobile, making reviewing and merging pull requests much easier on the go!
Read more about GitHub Mobile and send us your feedback to help us improve.
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:
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
