We've made some updates to how paste formatting works in Markdown-enabled fields on GitHub. For example, in code editors and on gists, you'll now be able to paste URLs on selected texts that will render as Markdown links like [...](https://...) by using the keyboard shortcut cmd|ctrl + v.
The following paste formatting changes have been made to pull requests, issue comments and wikis:
Spreadsheet cells and HTML tables will render as Markdown tables
Any copied text containing links will render the links in Markdown
All of this formatting can be disabled when pasting using the keyboard shortcut: cmd|ctl + shift + v or cmd|ctl + shift + Alt + v.
Previously, some branch protections only allowed exceptions to be granted to users and teams. Now, GitHub Apps can also be granted exceptions to any branch protection that supports exceptions.
Admins can create branch protection rules to enforce certain workflows for branches, such as requiring a pull request before changes can be merged to a branch. This is a good practice, but you may want to make exceptions to a rule for specific people, teams, or GitHub Apps. For example, if you have a GitHub App that calls GitHub APIs to make changes in a repository, you may want to permit that App to make changes without creating a pull request. Previously, these exceptions could be granted to people and teams, but only some protections allowed GitHub Apps.
Now, branch protections that previously only allowed exceptions for people and teams also support GitHub Apps. When admins configure these branch protections, they can choose from a list of GitHub Apps that are installed and authorized for the repository, as shown here:
We've added an enhancement to the repository view for a branch that is different than its upstream branch. Previously we showed the number of commits the branch was ahead or behind the upstream, but there wasn't an easy way to show the differences. Now you can click a link that takes you to a comparison page to see the differences.
Note: there is a different link for ahead versus behind
ahead represents changes your branch has but the upstream branch does not
behind represents changes the upstream branch has but your branch does not
You can now default to using PR titles for all squash merge commit messages. Navigate to 'Settings' in your repository and scroll down to the Pull Requests section. Select Allow squash merging and then select Default to PR title for squash merge commits. You can learn more about how to configure squash merge commits here.
To further reduce the risk of a user using Actions to merge a change into a protected branch that was not reviewed by another person, the organization setting to disallow Actions from approving pull requests, which was introduced in January 2022, has been extended to also limit Actions from creating pull requests.
The Allow GitHub Actions to create and approve pull requests setting can be managed by admins in organization settings under Actions > General > Workflow permissions.
When a new issue or pull request is created and not yet submitted, the assignees, reviewers, labels and projects will all be preserved upon page refresh.
You can now require a successful deployment of a branch before its pull request can be merged. This is made possible by a new branch protection setting titled Require deployments to succeed before merging. To enable the setting, create a new branch protection rule for the target branch. Then, select the environments where deployments must succeed before a pull request can be merged, shown here:
This will allow you to ensure code is, for example, exercised in a staging or test environment before it's merged to your main branch.
Previously, GitHub's web UI did not allow deleting a branch that was associated with an open pull request. Now you can delete such a branch from the UI. However, doing so will close all open pull requests associated with the branch. Before the branch is deleted, you must confirm that the pull requests may be closed.
Today, we are announcing the beta of the new file tree experience for pull requests!
Jump between files more quickly
Understand the size and scope of the change before you start reviewing
Focus your review by filtering the tree on part of a file or folder name
How to use the tree
On the Files changed tab of a pull request, click a file in the tree to see its changes.
To filter the tree, type into the Filter changed files text input. File names matching this input and all files under a folder name matching this input will be shown. You can also filter the tree by file extension, viewed or not, owned by you or your team, and more using the File filter menu.
To hide or show the tree, click the toggle button above the tree.
Note: The file tree only appears if the pull request has at least 2 changed file and your browser window is sufficiently wide. During the beta, you can disable the tree completely via the feature preview dialog. When disabled, you will no longer have the option to hide or show the tree from the pull request page. If you change your mind, you can re-enable the tree in the feature preview dialog.
We want to hear from you
Join the public discussion and tell us what you like and don't like about the new file tree.
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.
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:
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:
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.
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.
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.
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.
toggle button above the tree.
