The refreshed pull request commits page, which was previously in public preview, is now generally available! This updated page improves performance, is more consistent with other pages across GitHub, and is accessible to more users.
Your feedback during the public preview helped us deliver a better experience, including better keyboard navigation. If you have additional feedback, please let us know in the GitHub Community.
Repository rules now allow you to enforce which merge methods are available when merging pull requests into a specified branch. The merge method rule is available for rulesets at the repository, organization and the enterprise level. Allowing you to choose between merge commit, squash, or rebase to ensure only the selected merge methods are allowed on the targeted branches across the user interface and APIs.
Learn more in the documentation and join the discussion within GitHub Community.
To help you better understand the state of your pull request and get it merged faster, the merge experience on the pull request page has been improved! This experience is currently in public preview.
We’ve maintained the familiar look of the existing merge experience while incorporating several usability improvements:
For a more complete list of changes visit the feedback discussion.
This improved experience is rolling out gradually and is turned off by default. Once it becomes available to you, a Try the new merge experience link will appear below the merge box on the pull request page:
Click it to switch to the improved experience. A link is also available for easily switching back to the existing experience. You can also toggle the experience via the feature preview dialog.
As this experience is in public preview, you may run into some bugs and missing features (let us know when you do). Some of the known issues include:
For a more complete list of known issues visit the feedback discussion.
We want to hear from you! To provide feedback, ask questions, and see a list of known issues, visit the GitHub Community improved merge box discussion!
Code reviews and suggestions from colleagues, integrators, and AI agents like Copilot code review and Copilot autofix increase your code’s quality, but at times they can get overwhelming. You can now use Copilot Workspace directly in the context of your pull request to quickly refine, test, and incorporate code review feedback and suggestions from teammates and AI agents. Ship faster without compromising quality.
To get access, sign up for the waitlist here. This will also give you access to Copilot code review.
Using Copilot Workspace in your PRs, you can:
For more information see our documentation, or join the discussion within GitHub Community.
The pull request commits page has been refreshed to improve performance, improve consistency with other pages, and to make the experience more accessible!
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.
To switch back to the classic commits page, disable the “New Pull Request Commits Experience” feature preview (learn more).
To provide feedback, ask questions, learn about known issues, visit the GitHub Community feedback discussion!
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. 🎉
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.
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.
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.
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:
We are excited for you to experience the new comment box and we welcome feedback to continue improving GitHub for everyone.
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.
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.
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.
Click here to learn more. If you have feedback, please share and let us know in our community discussion.
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.
Requiring Actions workflows with Repository Rules is now generally available on GitHub.com!
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!
Repository rule insights now make finding more details about how someone merged specific code into your repos even easier.
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.
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.
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.
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}
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.
To help users better understand the state of a pull request, we now provide more details in two specific cases.
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.
Note: this message only appears when using rulesets.
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.
Repository rules are now generally available on GitHub.com.
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.
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. 
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.
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:
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.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 createdpull_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.For more on how to get started with merge queue, check out details on our blog!
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!