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

Comments on individual commits made outside a pull request no longer appear in the pull request timeline

Code review on GitHub has evolved a lot since we introduced the ability to comment on an individual commit in 2008. Users today can propose a change using a pull request, which provides a first-class experience for reviewing, discussing, evolving, and ultimately accepting or rejecting a change. While pull requests are the recommended way to review and discuss proposed changes, commenting on individual commits is still currently supported.

We recently rolled out a change to no longer show comments added to individual commits (comments added outside the context of a pull request) on the pull request timeline. Previously, if a pull request happened to include a commit that had commit comments, those comments would appear on that pull request’s timeline. Users often reported that these comments were irrelevant to the pull request or caused confusion when added by someone not involved in the review.

Note: this change does not impact the ability for users to comment on individual commits or review a pull request one commit at a time.

Comparing commit comments and review comments

To help understand this change, let’s compare commit comments with pull request review comments.

A commit comment is a comment added by a GitHub user to an individual commit or to a line of a file changed in a commit. Commit comments are stored on GitHub and surface in various places in the GitHub UI, including at the bottom of the commit page (/:org/:repo/commit/:sha):

image

A commit comment is associated with a commit. A commit comment cannot be added from the pull request page and cannot be replied to or resolved like a pull request review comment because it does not belong to the pull request. A commit comment can be indirectly associated with a pull request if that pull request includes the commit.

A pull request review comment is a comment added by a GitHub user to a changed line (or the lines surrounding it) in a pull request. Review comments are usually added from the Files changed or Commits tab of the pull request page and are directly associated with the pull request.

image

Unlike commit comments, pull request review comments do not surface outside the context of the pull request since they belong to the pull request.

What changed

Prior to this change, comments on individual commits (made outside the context of the pull request) would appear in the timeline of any pull request that included that commit:

image

With this change, commit comments (like the highlighted 029541b comment) no longer appear in the pull request timeline.

The timeline events REST and GraphQL APIs also no longer return commit comments associated with any commits included in the pull request.

What did not change

This change did not impact a user’s ability to add, view, or manage comments on individual commits.

  • Users can still add comments to individual commits or changed lines in a commit
    image
  • Users can still review pull requests one commit at a time and add review comments
  • Commit comments still surface on the commits listing page
    image
  • Commit comments still surface at the bottom of the commit page
  • Commit comments are still accessible from the Commits tab of the pull request page
    image
  • Commits pushed to a pull request head branch still surface in the timeline and on the Commits tab of the pull request page

There was also no impact to commit messages, i.e. the message stored with the Git commit. Commit messages continue to surface everywhere they previously surfaced, including on the pull request page.

We want to hear from you

If you have feedback or questions about this change, let us know here: https://github.com/orgs/community/discussions/28924

See more

Autolinks with alphanumeric IDs

Previously, when creating an autolink reference for a repository, you could only use a numeric identifier in the <num> parameter. This format didn't support integration with platforms that use alphanumeric identifiers, like the last segment of this Trello card URL: https://trello.com/c/3eZr2Bxw. Now you can create an autolink with an alphanumeric identifier.

Any previously created autolinks will continue to support only numeric identifiers so that they continue working as before. Only newly created autolinks will support alphanumeric identifiers.

Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub's products.

Learn more about autolinks at Configure autolinks in the GitHub documentation. We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Deferred syntax highlighting

Pull Requests will now load more quickly thanks to deferred syntax highlighting.

When you first land on a Pull Request’s Conversation or Files tab we will show plain text diffs, and then swap in the syntax highlighted versions as soon as they are ready.

See more

Users can view and comment on code scanning alerts on the Conversation tab in a pull request

Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.

And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.

Code scanning alert

Code scanning and branch protection rules

Users were already able to configure code scanning as a required check in the branch protection settings in a repository.

With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.

As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.

PR merge blocked because of unresolved conversation

Learn more about GitHub Advanced Security and code scanning.

See more

GitHub Actions: Re-run jobs with debug logging

You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures.

To enable debug logging, select "Enable debug logging" in the re-run dialog.

Re-run dialog screenshot

You can also enable debug logging using the API or the command-line client.

For more details see
Re-running workflows and jobs.

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

See more

Updates to Markdown pasting on GitHub

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.

markdown formatting demo gif

Learn more about writing and formatting at GitHub.

See more

Consistently allow GitHub Apps as exceptions to branch protection rules

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:

Image of adding a GitHub App as an exception to a branch protection setting

For information about branch protection rules, visit Managing a branch protection rule.

For information about GitHub Apps, visit About GitHub Apps.

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Compare differences between branches

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.

image

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

Read more about branches.

See more

GitHub Actions: Prevent GitHub Actions from creating and approving pull requests

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.

image

See more

Required Deployments

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:

image

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.

Learn more about protected branches
Learn more about branch protection rules

See more

Delete a branch with an open pull request

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.

Confirm deleting a branch

Read more about working with branches.

Read more about collaborating with pull requests.

See more

Pull Request File Tree (Beta)

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.

PR Files Changed tab showing tree

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.

Learn more

Learn more about reviewing proposed changes and filtering files in a pull request.

See more

CODEOWNERS improvements (syntax errors, preview of who will be requested, and more)

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

Image previews now shown by default when comparing differences

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

More ways to keep your pull request branch up-to-date

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

GitHub Actions: Prevent GitHub Actions from approving pull requests

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

Ensure required status checks provided by the intended app

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

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
View more changes