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

Rebase commits now created using the merge-ort strategy

Last year, we made merging pull requests much faster by using the merge-ort strategy. Now, rebase commits get the same merge-ort treatment. This results in significantly improved speed: the P99 (the average time to complete rebases excluding the 1% slowest outliers) used to take around 3.6 seconds. P99 with the new strategy is 0.35 seconds. Because of the speedup, the fraction of PR rebases which fail due to timeouts dropped from 1.3% to 0.14%.

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

See more

Repository Rules public beta updates

We are introducing a number of enhancements, bug fixes and a breaking API change to repository rules.

1. UI Updates
* Added a repository picker to target select repositories for organization rulesets.
* Improvements to rule violations in the WebUI and git client.

2. Ruleset Bypass updates

  • Bypass can be limited to pull request exemptions only.
  • Single UI for bypass, collapsing bypass mode, and bypass list into one experience.
  • Support for using repository roles as a bypass type
  • Integrations (bots/apps) are now bypassable at the org.

3. API Enhancements

  • Add fields for created and updated date
  • Permission changes so all repo contributors can query the API for relevant rules enforced on branches.

4. Bug fixes

  • Linear merge history could block bypass
  • Branches could not always be created when using commit metadata rules
  • Tag protections were failing for apps

5. API Changes

  • GraphQL changes will be delayed by 24-72 hours.
  • Breaking Change Remove bypass_mode from the Ruleset object and input
  • Breaking Change Add bypass_mode as a required field for bypass actors to indicate if an actor can “always” bypass a ruleset or can only bypass for a “pull_request”
  • Breaking Change for GraphQL Change bypass_actor_ids to a new bypass_actors object on the create and update mutations that can accept repository roles and organization admins
  • Add repository_role_database_id, repository_role_name, and organization_admin fields to RepositoryRulesetBypassActor to indicate when the bypass actor is a role or org admin bypass
  • “get rules for a branch” REST API endpoint now returns ruleset source info for each rule.
  • “get a repo ruleset” REST API endpoint now has a current_user_can_bypass field that indicates whether the user making the request can bypass the ruleset.
  • source field for rulesets returned via the REST API will now properly contain the repo in owner/name syntax when the ruleset is configured on a repository, rather than just the repository’s name.

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

See more

Fix to improve security around creation of pull requests in public repos

We've shipped a small fix to improve security around creation of pull requests in public repos.

Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.

This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.

We want to hear from you! Let us know if you have questions or feedback.

See more

Security enhancements to required approvals on pull requests

Announcing important changes to what it means for a pull request to be 'approved'.

If you use pull requests with protected branches, there are some important security improvements rolling out now that may impact your workflow:

  • Merge commits created locally and pushed to a protected branch will be rejected if the contents differ from the system-created merge.
  • The branch protection for dismissing stale reviews now dismisses approvals whenever a merge base changes after a review.
  • A pull request approval now only counts towards the pull request it was submitted against.

Note: You may see some older approvals dismissed as we rollout these changes.

Read on to learn more about the specific changes:

User-created merges must have the same contents as the system-created merge.

Previously, it was possible for users to make unreviewed changes to a protected branch, by creating the merge commit locally and pushing it to the server. The merge would be accepted, so long as the parents commits were set correctly.

Going forward, manually creating the merge commit for a pull request and pushing it directly to a protected branch will only succeed if the contents of the merge exactly match the system-generated merge for the pull request. This new check will be enforced on branches where the branch protections mentioned earlier are enabled.

Pull request approvals will become stale if the merge base changes
A pull request approval will be marked as stale when the merge base changes after a review is submitted.

The merge base of a pull request is the closest common ancestor of both the target and source branches for that pull request. It is often (but not always) the commit where a user has branched off the mainline development and started working on a topic branch:

228341522-a954ade3-a4e2-4703-8920-8c3220e2ff0d

When "dismiss stale approvals" is enabled, the review will be dismissed and needs a re-approval. If branch protection rules specify that every push needs to be reviewed by a second contributor, a change in the merge base will require fresh approvals.

Merge bases changing under a pull request will preserve approvals in most situations where no new changes are introduced.

Pull requests no longer combine approvals.
Previously it was possible for a branch protected by "required pull request review" to be merged without an approved PR. This was possible because approvals were gathered across multiple independent pull requests if the feature branches pointed to the same commit as well as targeting the same branch.

We appreciate your feedback in GitHub's public feedback discussions.

See more

More secure private attachments

Previously, all attached (drag-and-dropped) images and videos on GitHub Issues, Pull Requests, Discussions, and wikis were available to view without authentication if you knew their direct URL. Now, future attachments associated with private repositories can only be viewed after logging in. This doesn’t apply retroactively to existing attachments, which are obfuscated by having a long, unguessable URL.

Email notifications sent from private repositories will no longer display images; each image is replaced by a link to view it on the web. Content inside a Git repository is not affected by this change and has always required authentication for private repositories.

Learn more about attaching files.

Questions or suggestions? Join the conversation in the community discussion.

See more

Pull request merge queue (public beta): API support and recent fixes

As we work towards general availability of pull request merge queue, we want to thank everyone that has provided feedback ❤ (keep it coming!) and let you know about some recent fixes and new API support.

See the public beta announcement to learn more about merge queue and how it can help increase velocity by automating pull request merges into your busiest branches.

🆕 API support

You can now interact with merge queue programmatically using new GraphQL APIs. Add or remove a pull request from the queue, see which pull requests are queued, get details about a queued pull request, and more. For example:

Call the enqueuePullRequest mutation to add a pull request to the queue or dequeuePullRequest to remove a pull request.

Use the mergeQueue field on Repository to list its contents or configuration. Use the mergeQueueEntry field on PullRequest to get details about a queued pull request including its state, position in the queue, estimated time to merge, and more.

🐛 Fixes

Some of the more noteworthy fixes made since the public beta launch:

  • Fixed: GitHub Actions workflows would not trigger on merge_group events in some repos
  • Fixed: failing queued pull request would remain failing even after checks were rerun and and passed
  • Fixed: confusing “pushed a commit that referenced this pull request” message would appear in the timeline
  • Fixed: commits could be pushed to queue-created prep branches (note: these commits were ignored and not merged, but it created confusion for some users)

Get started

Interested in merge queue? Learn how to get started.

Questions or suggestions? Join the conversation in the merge queue public beta discussion.

See more

Introducing Repository Rules Public Beta

Today we are announcing the public beta of repository rules! 🎉

Repository rules are GitHub’s next evolution of branch protections to help make your repositories more secure and compliant at scale.

Screenshot of ruleset overview

Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.

Creating rules

Screenshot of creating a ruleset

At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.

The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.

When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be merged, while disabled rulesets are not enforced; they will not prevent merges but allow admins to craft rules before enforcing them. Enterprise Cloud customers can also evaluate rulesets: a “dry run” mode for understanding the impact of new rules before they are active and enforced.

It’s also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.

Viewing the rules

You can always know what rules are in place for a repository.

Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.

From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.

Screenshot of read only view of rules

Getting Started

Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.

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

See more

Commenting on files in a pull request is now generally available

Commenting on files (including deleted, binary, and renamed files) in a pull request is now generally available on the web and GitHub Mobile! A special thank you to everyone that provided feedback during the public beta.

API support is also now available. See create a review comment (REST API) or addPullRequestReviewThread (GraphQL mutation) for more details on commenting on files. A new "subject type" field is also now returned by other APIs indicating whether a comment is on a line or file.

Learn more

Learn more about commenting on a pull request.

See more

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