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

The pull request commits page has been refreshed to improve performance, improve consistency with other pages, and to make the experience more accessible!

Screenshot of the updated PR commits page showing a list of commits for a PR

To minimize disruptions, the capabilities of the classic commits page have been maintained, with a few exceptions: you can now use arrow keys to navigate the list of commits (instead of j and k) and focus indicators have been improved for better visual distinction.

Opt out

To switch back to the classic commits page, disable the “New Pull Request Commits Experience” feature preview (learn more).

Feedback

To provide feedback, ask questions, learn about known issues, visit the GitHub Community feedback discussion!

See more

Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉

A glimpse of push rules in action

You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to the repository network are protected.

Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.

Learn more about push rules in our documentation and join the community discussion to leave feedback.

See more

PR review improvements

We’ve got some exciting news to share! We’ve been closely listening to your feedback, and one common challenge many of you faced was reviewing, and submitting your pull request reviews on GitHub Mobile. We heard you loud and clear, and today, we’re thrilled to announce that approving PRs is now easier than ever before!

With our latest update, we made it easier to start, continue, and submit your code reviews on the go.

Now, whether you’re on the train, grabbing a coffee, or simply away from your desk, you can effortlessly contribute to your projects and keep the momentum going.

Download or update GitHub Mobile today from the Apple App Store or Google Play Store to get started.


Learn more about GitHub Mobile and share your feedback to help us improve.

See more

We are excited to announce a significant update to the comment box used in GitHub issues, discussions, and pull requests, aiming to refine and enhance how you interact and collaborate. This release is a testament to our ongoing efforts to provide an exceptional user experience, making GitHub more intuitive, consistent, and accessible across the platform.

A screenshot of the new comment box

The updated comment box is designed to integrate seamlessly with the existing GitHub environment, ensuring a familiar yet improved experience for all users. Highlights and improvements include:

  • Enhanced User Experience: The newly revamped comment box brings an elevated experience to a wider range of users across various devices. With this update, we've enhanced the responsiveness and streamlined the markup to better accommodate keyboard and screen reader users. This ensures a uniform and smooth user experience across issues, discussions, and pull requests, promoting seamless communication and collaboration.
  • Consistency and Familiarity: Our design philosophy for the new comment box was clear: keep it familiar, make it better. We’ve developed the updated version to closely resemble the original while enhancing it with improved accessibility, consistency, and ease of use across various screen sizes. The transition for you will be smooth, with no disruptions to your workflow.
  • Commitment to Accessibility: This update contributes to our continuous journey to make GitHub more accessible to everyone. The comment box now aligns more closely with our accessibility commitment, enhancing the experience in features such as issues, pull requests, and discussions. Check out our Accessibility Commitment to learn more about how we are making GitHub more inclusive.

We are excited for you to experience the new comment box and we welcome feedback to continue improving GitHub for everyone.

See more

Need to roll back a change to a ruleset? How about easily moving your ruleset around?

With today’s public beta you now have new tools to manage your ruleset.

Import and Export

Rulesets are now easier to share and reuse, with the ability to import and export rulesets as JSON files. Giving you the ability to share rules across repositories and organizations or to share your favorite rules with the community. Which is what we’re doing. The ruleset-recipes repository is home to a collection of pre-baked rulesets covering a number of popular scenarios ready for you to use.

Gif walking through the steps outline above to import a ruleset from a JSON file.

History

If you are a repository or organization administrator of GitHub Enterprise cloud, we’re adding a history experience so you can track changes and revert rulesets. Now, it’s easy in the ruleset UI to see who changed a ruleset, when it happened, and what changed. Then, quickly get back to a known good state.

Only changes made to a ruleset after the public beta are included in ruleset history.

Gif walking through the step of using history, and selecting a ruleset version to restore.Screenshot of Ruleset history comparison screen.

Click here to learn more. If you have feedback, please share and let us know in our community discussion.

See more

PNG Custom Properties Header.

Starting today, organization administrators can create custom properties to enrich repositories with valuable information. Using these properties, you can dynamically target repository rules to apply protections on just your production repositories or to a business unit or any other way you want to classify your repositories.

Only organization administrators can configure custom properties; you can be confident knowing that they are not accidentally removed by a repository administrator, ensuring your branch and tag rules are consistently applied. Property values can also be automatically applied with default values at repository creation, ensuring every new repository is classified, and its first commit is protected.

Today, organization administrators can only use custom properties for dynamically targeting rulesets. But soon, you can use properties to filter and search in an updated repository list and other experiences across GitHub.

Learn more about managing custom properties for your organization and managing rulesets for your organization.

Head over to community discussions for feedback

See more

Requiring Actions workflows with Repository Rules is now generally available on GitHub.com!
Screenshot showing the add required workflow modal overtop the enabled rule inside a ruleset

Through Repository Rules, GitHub Enterprise Cloud customers can now set up organization-wide rules to enforce their CI/CD workflows, ensuring workflows pass before pull requests can be merged into target repositories. Additional settings allow for fine-tuning how the workflow file can be selected — either from a specific branch, tag, or SHA — and provide maximum control over the version expected to run.

Applying a newly created workflow policy across an organization can feel risky. To ensure confidence when enabling a workflow rule across targeted repositories, workflow rules can be put into “evaluate” mode which will validate the rule is working correctly. And don’t worry, organization administrators can even allow select roles to “break the glass” and bypass a rule when necessary.

Learn more about this release and how requiring workflows with Repository Rules can protect your repositories.

To share feedback or ask questions, join our Community Discussion!

See more

Repository rule insights now make finding more details about how someone merged specific code into your repos even easier.

🔍 Filter by status

If you want only to see bypassed rules, you can now filter rule insight by the status of the results.

No more scrolling through and sorting through all the insight activity to find that one bypass situation. You can now filter by All Statuses, Pass, Fail, and Bypass.

Overview of selecting different rule insights status types. And showing the change between pass, fail, and bypass

👀 Clamoring for more insight into your rule insights?

Well, now you have access to way more information, including who ✅ approved and ❌ denied a pull request. As well as having access to the results of all required status checks and deployment status states right in rule insights.

Rule insight instance showing a specific passed status check.

👩‍💻 REST API Endpoint

Want to look for ruleset failures for a specific app programmatically?
With the new REST endpoint, you can now view and query rule insights via your favorite API tools.

Repository Endpoint

All repo insight activity

–  GET http://api.github.com/repos/{owner}/{repo}/rulesets/rule-suites

Specific insight rule suite for a repository ruleset
–  GET http://api.github.com/repos/{owner}/{repo}/rulesets/rule-suites/{rule _suite_id}

Organization Endpoint

All org insight activity
–  GET http://api.github.com/orgs/{org}/rulesets/rule-suites

Specific insight rule suite for an organization ruleset
–  GET http://api.github.com/orgs/{org}/rulesets/rule-suites/{rule_suite_id}

Click here to learn more. If you have feedback, please share and let us know in our feedback discussion.

See more

To help users better understand the state of a pull request, we now provide more details in two specific cases.

Merged indirectly

If a pull request's commits are merged into the base branch by another pull request (or directly), the pull request is still marked as merged, but previously, it was not clear from the timeline that the pull request was merged this way. This could result in confusion if the pull request was still awaiting approvals or had failing status checks. Now, the timeline provides more details, including a link to the merged pull request that caused the pull request to be marked as merged.
image

Note: this message only appears when using rulesets.

Pushed commits are still being processed

If new commits are pushed to a pull request's branch and it takes longer than usual for them to be processed and appear in the commit list, an informational message is now presented at the top of the pull request page.
image

See more

Repository rules are now generally available on GitHub.com.

Screenshot of Repository Rules overview

Repository rules allow you to easily govern protections for branches and tags on your repositories. Repository collaborators also gain access to see what rules are in place via the Web, git client, and the GitHub CLI.

For GitHub Enterprise Cloud customer, you gain the ability to enforce branch and tag protections across repositories in your organization. As well as insights on rule enforcement, evaluation mode to test rules before enforcing them and governance around commit messages.

Check out the blog post to learn more about repository rules. And if you have feedback, please share and let us know in our feedback discussion.

See more

Today we are announcing the general availability of pull request merge queue! 🎉

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

Before merge queue, developers would often need to update their pull request branches prior to merging to ensure their changes wouldn't break the main branch because of incompatibilities with pull requests already merged. Each of these updates caused a new round of continuous integration (CI) checks that would have to finish before the developer could attempt to merge. Merge queue automates this process by ensuring each pull request queued for merging is tested with any other pull requests queued ahead of it.

Merge queue is available on private and public repos on the GitHub Enterprise Cloud plan and all public repos owned by organizations.

Check out this video demo of how merge queue works.

Updates

Over the last few months, we've been busy fixing bugs and responding to feedback. As part of the general availability, we're announcing the following updates:

  • New: A merge_group webhook event with an action of destroyed is now published when a merge group is destroyed for any reason, including when it's merged or invalidated because a pull request is removed from the queue.
  • Fixed: The before and created properties of the push webhook event published when a temporary branch is created by the queue are now set to reflect a branch was created
  • Changed: Jumping to the front of the queue is now only available to admins by default in repos on GitHub Enterprise, but can be granted to individual users and teams using a custom repository role. Previously, any user with write access could jump the queue, but admins did not have a way to limit access to it or grant it to users without write access.
  • Fixed: A pull_request.dequeued webhook event is now consistently published whenever a pull request is removed from the queue for any reason, including when it has been merged by the queue.

Learn more

For more on how to get started with merge queue, check out details on our blog!

A special thanks

A huge shout out and thank you to our customers in the community that participated in the public beta of this feature. Your input will help teams prevent traffic jams on their busiest branches! Hooray!

See more

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

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

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