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.
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!
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
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.
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.
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:
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.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
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.
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.
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.
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.
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.
👀 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.
👩💻 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}
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.
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.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
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.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
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.
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! ✨
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
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%.
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.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
We've shipped a fix to ensure merges by the pull request merge queue are always attributed to the GitHub Merge Queue bot (github-merge-queue[bot]). This change applies to new merges by the queue, and will appear in the activity view and in push webhook events.
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.
