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

Introducing the GitHub Markdown Helpers Public Beta

GitHub users write a lot of Markdown; so much so that we render 2 billion Markdown files everyday; at peak times, we're processing 1,300 Markdown files a second! Any opportunity we have to shave a few seconds off of the Markdown authoring experience on GitHub is time well-spent.

Introducing Markdown Helpers powered by Slash Commands

To use Markdown Helpers, simply type / on Issues, Pull Requests, or Discussion descriptions/comments and use the subsequent dialog to choose from a number of useful Markdown shortcuts.

Use shortcuts like /table to make Markdown tables a breeze, or /details to make selectively showing content to readers much easier than remembering the HTML formatting.

As part of our first release, we've included 6 out-of-the-box features which we hope will help teams author Markdown faster and with less context switching:

  • Code Block
    • Support for language-specific syntax highlighting
  • Details
    • Specify details that the reader can open and close on demand
  • Saved Replies
  • Table
    • Easily insert Markdown Tables
  • Templates
    • Easily populate your Repository's Issue or Pull Request templates directly from Slash Commands!
  • Tasklist
    • Easily insert a Tasklist
    • Note: Tasklists are currently in Private Beta, only users in organizations added to the Private Beta will see this option)

We'd love to hear from you!

Be sure to check out the official Slash Commands documentation for more details on the commands we're releasing today.

Anything we missed? Got an idea for a great Slash Commands feature?

Please leave us some feedback in our Feedback Discussion about how you'd like to use Slash Commands on GitHub.

See more

Comment on files in a pull request (public beta)

Commenting directly on a file in a pull request (not just a specific line) is now available in public beta! 🎉

With this capability you can now comment on deleted, binary (including images), and renamed files in a pull request. You can also comment generally about a changed code file without having to attach the comment to a specific line.

How it works

To comment on any file in a pull request, click the Comment on this file button in the header of the file (next to the Viewed checkbox):
image

Comments on files appear in the Files Changed and Conversation tabs and can be replied to and resolved like regular review comments.
image

Tell us what you think

This feature is currently in public beta, with GitHub Mobile and API support coming soon.

Join the discussion and let us know what you think!

See more

Feature Preview: Rich Jupyter Notebook Diffs

Rich diffs of Jupyter Notebook files in pull requests are now available in preview. With the feature preview enabled, you can compare cell-level inputs and outputs (including images), as well as notebook and cell metadata, thanks to nbdime. Check it out:

image

The rich diff functionality will need to be enabled via the Feature Preview menu found when clicking on your avatar. Click here to learn more about feature previews and how to enable it. Please note that this is an early-access feature and there are some limitations; most notably, you cannot currently comment on lines in rich diff mode and will need to toggle the source diff to do so.

We'd love to hear from you! Once you try it out, let us know what you think in this feedback discussion. Stay tuned for future updates!

Note: If you were previously enrolled in the private beta for this feature and no longer see rich diffs, you may have to re-enable the feature preview via the menu.

See more

Manage branch protection rules with a new permission

You can now create a custom role to manage branch protections without having to grant the Admin role. Previously, to manage branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Edit repository rules permission, allowing just the right amount of access.

Image of Custom roles that shows the new Edit Repository Rules permission

This permission grants the ability to create, edit, and delete both branch protection rules and protected tags.

For more information, visit Managing custom repository roles for an organization in the GitHub documentation.

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

See more

Pull request merge queue (public beta)

Today we are announcing the public beta of pull request merge queue for repos on GitHub Enterprise Cloud and open source organizations! 🎉

Merge queue helps increase velocity in software delivery by automating pull request merges into your busiest branches.

Pull request merge queue

Before merge queue, developers were often required to update their pull request branches prior to merging to ensure their changes wouldn't break the main branch when merged. Each update resulted in a fresh round of continuous integration (CI) checks that would have to finish before the developer could attempt to merge. If another pull request got merged, every developer would have to go through the process again.

Merge queue automates this process by ensuring each pull request queued for merging is built with the pull requests ahead of it in the queue.

Queueing a pull request to merge

If your pull request targets a branch that uses merge queue, instead of merging your pull request directly when it meets the requirements to merge, you will add it to the queue by clicking Merge when ready from the pull request page or from GitHub Mobile.

Queue to merge

The queue then creates a temporary branch that contains the latest changes from the base branch, the changes from other pull requests already in the queue, and the changes from your pull request. CI then starts, with the expectation that all required status checks must pass before the branch (and the pull requests it represents) are merged.

If a queued pull request has merge conflicts or fails any required status check, it is automatically removed from the queue when it reaches the front, and a notification is sent. Once the problem is resolved, it can be added back to the queue.

Learn more about merging a pull request with merge queue from the pull request page. You can also queue your pull request on the go using the beta version of GitHub Mobile from iOS TestFlight or Google Play (Beta)!

Viewing the queue

Always know where you are in the queue.

The queue details page, which can be accessed from the Branches page or pull request page, shows the pull requests in the queue and status for each, including the required status checks and estimated time to merge. It also shows how many pull requests have been merged and the trend over the last 30 days.

Merge queue details page

Depending on your permissions, you can also remove a pull request from the queue or clear the queue from this page.

Getting started

Merge queue can help improve overall velocity and avoid manual branch updates that impact developer productivity. Learn more about how to enable merge queue on your busiest branches.

We want to hear from you on how we can improve merge queue! Join the conversation in the merge queue public beta discussion.

See more

New Branch Protections: Last Pusher and Locked Branch

Today we're releasing two new branch protections.

Require approval from someone other than the last pusher

Now, before a pull request can be merged, you can require it to be approved by someone other than the last pusher.
Meaning, the most recent user to push their changes will need a pull request approval regardless of the Require approvals branch protection. Or in the case of 1 approval required, someone other than the last user to push their changes will also need to approve. If the approvals come from other folks than the last pusher, those two approvals will be sufficient.

Screenshot of Last Push protection enabled.

Lock branch

This allows for branches to be locked, prohibiting changes. You can lock a branch allowing you to have a maintenance window and prevent changes, or to protect a fork so it only receives changes from its upstream repository.

To use this feature in a branch protection rule, enable Lock branch.

Screenshot of Lock branch with fork sync enabled

For more information, read About protected branches in the GitHub documentation.

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

See more

Reverted recent change that caused some pull requests to be incorrectly marked as merged

On September 5, 2022, we reverted a recent change to our indirect pull request merge logic that was causing some pull requests to be incorrectly marked as merged. This could happen if a pull request's head branch was force pushed and resulted in the pull request showing no new commits compared to the base branch. The original change went live on August 1, 2022 and caused confusion about why some pull requests were marked as merged by a contributor who did not have the necessary permissions. It also had the side effect of removing the "first time contributor" flag from these contributors without them having made an accepted contribution by the repository maintainers. Depending on repository settings, this could have allowed first time contributors to run GitHub Actions workflows based on their branches.

At no point were users able to push changes or merge pull requests in repositories to which they did not have appropriate authorization. After the change was reverted, GitHub conducted an investigation into any bypasses of the "first time contributor" flag and found no evidence of abuse.

See more

Git commit author shown when squash merging a pull request

The author of the Git commit created when squash merging a pull request is now shown before merging. Previously, the commit author was only shown when merging with a merge commit.

image

Also, if the user merging the pull request also opened it and has multiple email addresses configured, a drop-down now lets them choose a different email address to use for the commit's author.

image

These improvements are designed to ensure Git commits created by squash merging are associated with the correct email address.

Learn more about merging a pull request.

See more

Merge commits now created using the merge-ort strategy

When GitHub creates merge commits, like to test whether a pull request can be merged cleanly or to actually merge a pull request, it now uses the merge-ort strategy. merge-ort is a relatively new Git merge strategy that is significantly faster (for example, complex merge commits that previously took 5 or more seconds to create are now created in less than 200 milliseconds) and addresses subtle correctness issues found in the merge-recursive strategy. And because merge-ort is the default merge strategy in the latest releases of Git, merge results are now more predictable and consistent between your local machine and GitHub.

Learn more about the Git merge-ort strategy and merge methods for pull requests.

See more

Better suggested pull request description from commit message

When opening a pull request from a comparison that only includes one commit, GitHub defaults the title and description to the subject line and body of that commit's message. Authors who write detailed git commit messages that adhere to the widely accepted convention of wrapping at 72 characters per line may have noticed that this can result in strange formatting because of how GitHub Flavored Markdown treats newlines.

We now take and automatically reformat the commit message when suggesting the pull request description, making it look just as good as the commit message it came from when viewed on github.com, GitHub Mobile, and other tools.

An image of a PR being opened before and after this change

Learn more about Creating Pull Requests

See more

Autolinks with alphanumeric or numeric IDs

Previously, we announced a change to how <num> parameters work for autolink references, switching from numeric to alphanumeric IDs. We heard from a number of customers who still need numeric identifiers. Now when creating an autolink reference, you can use an alphanumeric or numeric identifier.

Screenshot of Autolink references

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

New options for controlling the default commit message when merging a pull request

In May we shipped a setting for including the pull request title in the default commit message presented to users when squash merging a pull request. We just shipped more options for customizing the default commit message, including using the pull request's description! You can also now customize the default commit messages for merge commit merges. The goal is more predictable, consistent, and useful commit messages for your pull requests, which translate to a more useful Git commit history.

How it works

From repository settings, a maintainer or admin can choose the default format for commit messages produced when merging pull requests:
image

This selection is used to form a default commit message that gets presented to users on the pull request page when merging a pull request. For example, assume Default to pull request title and description is selected and a user clicks to merge a pull request with this description:
image

The default commit message will include the pull request's title and description:
image

The user can then accept this commit message or make changes before merging.

Options

For merge commit merging:

  • Default message: pull request number and head branch on the first line; pull request title on the third line
  • Pull request title: pull request title and number on the first line
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

For squash merging:

  • Default message: commit title and commit message (if the pull request contains a single commit), or the pull request title and number and list of commits (if the pull request contains multiple commits)
  • Pull request title: pull request title and number on the first line
  • Pull request title and commit details: pull request title and number on the first line; commit message (if a single commit) or list of commits (if multiple commits)
  • Pull request title and description: pull request title and number on the first line; pull request description starting on the third line

Additional details

If no message is provided when merging a pull request using the REST API or GraphQL mutation, a default commit message will be formed based on the selected message format and merge method.

The default message format can be managed using the Create a repository or Update a repository REST APIs. See the merge_commit_title, merge_commit_message, and squash_merge_commit_title, squash_merge_commit_message parameters.

Feedback

We want to hear from you! Tell us what you think and how we can make it better: https://github.com/orgs/community/discussions/30439

Learn more

Learn more about configuring merge commit merging and configuring squash merging.

See more

Merge group webhook event and GitHub Actions workflow trigger

This feature is available to repositories enrolled in the Pull Request Merge Queue beta.

A new webhook event and GitHub Actions workflow trigger (merge_group) makes it easier to run required status checks on merge groups created by merge queue. A merge group includes the changes from one or more pull requests and must pass the status checks required by the target branch.

A merge_group webhook event, which currently has one supported action (checks_requested), is sent after a merge group is created and informs receivers, including GitHub Actions, when status checks are needed on the merge group. The event payload includes head_sha, the commit SHA that should be validated and have status reported on using check runs or commit statuses. For GitHub Actions, status is reported automatically at the conclusion of jobs in the triggered workflow.

To trigger a GitHub Actions workflow for a merge group, the merge_group trigger should be used. The following example triggers on individual pull requests and merge groups targeting the main branch:

# Trigger this workflow on individual pull requests and merge groups that target the `main` branch
on:
  pull_request:
    branches: [ main ]
  merge_group:
    branches: [ main ]

A push event is still sent when a merge group branch is created, and will trigger a GitHub Actions workflow. However, unlike a merge_group event, a push event does not include the target branch of the merge group.

Learn more about using merge queue.

Learn more about the new GitHub Actions merge_group workflow trigger and the merge_group webhook event.

See more

Bypass branch protections with a new permission

You can now create a custom role to bypass branch protections without having to grant the Admin role. Previously, to bypass branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Bypass branch protections permission, allowing just the right amount of access.

Image of Custom roles Inherited from Maintain role that adds the new Bypass branch protections permission

To enforce branch protections for all Admins and roles with the "Bypass branch protections" permission, enable Do not allow bypassing the above settings in your branch protection rules.

Image of checkbox selecting Do not allow bypassing the above settings

This permission differs from the Push commits to protected branches permission, which allows pushing to a protected branch, but branch protection rules will still apply and could result in a push being denied.

For more information, visit Managing custom repository roles for an organization in the GitHub documentation.

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

See more

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