GitHub Enterprise Cloud customers with enterprise managed users (EMUs) can now make use of private wikis in EMU user-namespace repositories. These wikis can only be accessed by authorized users from the EMU enterprise, and cannot be made public.
Learn more about wikis.
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.
A total redesign of GitHub’s code search and navigation was released to all logged in GitHub users in May. Starting today, the new redesigned code navigation experience, including a file tree and symbols pane, will be available to anyone browsing anonymously on GitHub.com. To access the new code search experience, and make full use of the symbol navigation, create an account or log in to GitHub.com.
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.
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
3. API Enhancements
4. Bug fixes
5. API Changes
bypass_mode from the Ruleset object and inputbypass_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”bypass_actor_ids to a new bypass_actors object on the create and update mutations that can accept repository roles and organization adminsrepository_role_database_id, repository_role_name, and organization_admin fields to RepositoryRulesetBypassActor to indicate when the bypass actor is a role or org admin bypasscurrent_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.
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:
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:
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.
We've now made it easier to understand changes to your repositories with the new activity view. Historically viewing pushes to a repository required contacting GitHub support. This new activity view gives users with read access the ability to self-serve insights to a repository and all of its changes.
You can access the Activity view from the main page of a repository by clicking "Activity" to the right of the list of files.
You can also access the activity view from the Branches page of any repository by clicking on the activity icon.
From the activity view you can sort and filter to find exactly what you are looking for.
Here is an example of how you could use the activity view to find a force push on a particular branch, and then compare the changes to the repository before and after the push:
Learn more about the Activity view.
Already using the activity view? We'd love to hear your feedback.
At GitHub Universe last year, we announced a total redesign of GitHub's code search and navigation experience, powered by our all-new code search engine that we built from scratch. And in February, we announced our public beta.
Today, we are rolling out this feature to all GitHub users. Thanks to the members of the beta community for your excellent feedback and engagement throughout the beta!
Check out our blog post to learn more about how GitHub's new code search and code view can help you search, navigate, and understand your code. And if you have feedback, please share it with us in our feedback discussion.
You can now create new repositories with pre-filled form fields, making it even easier to define the right info for your new repos from the start.
There are a number of query string parameters available, including:
To get started you can craft a query string at the end of https://github.com/new starting with ? followed by the fields and their values.
See the example below for more details:
https://github.com/new?owner=octocat&name=new-boilerplate&description=A%20new%20boilerplate%20repository&visibility=private&template_owner=actions&template_name=boilerplate
Learn more about Creating a new repository
We appreciate your feedback in GitHub's public feedback discussions
When editing a file on github.com, repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now default to creating a new branch instead for directly committing. You can still commit directly to a protected branch, but doing so will add notifications in-line highlighting that some rules will be bypassed.
Historically the default behavior was to push through any branch protections with no notifications they were being bypassed.
Now we recommend creating a branch for admins eligible to bypass branch protection rules. This behavior occurs when adding new files to a repository as well as during pull requests.
We appreciate your feedback in GitHub's public feedback discussions
On March 30, 2023, we fixed a bug that allowed a dependency graph hovercard URL to be used to retrieve the name, description, and star count of any repository on GitHub.com. The bug was introduced on March 28, 2023 and our investigation has found no evidence of exploitation. To exploit the bug, a specific header needed to be set when making a request to the URL and the numeric ID of a repository provided. The URL would then return the HTML content designed to be used for a hovercard UI element with the repository name, description, and star count in the response.
This bug was reported to GitHub via the GitHub Bug Bounty program.
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.
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.
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.
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.
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.
After recently adding the archive date of repositories to the GitHub UI, the timestamp is now also available in GraphQL API responses.
Users can now query the archivedAt timestamp of when a repository was archived using the GitHub GraphQL API.
We now show bypassed branch protection rules in response to Git pushes. These are information messages and are not designed to block workflows.
Historically there was no indication after a Git push that branch rules had been bypassed.
Repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now see a list of rules that were bypassed.
We appreciate your feedback in GitHub's public feedback discussions
We've made improvements to the Forks Insights tab to give you much more information on the forks of your project. Now when you visit the Insights tab for a repository the Forks section will display a sortable and filterable list of forks. You'll also now see more details about each of the forks, like how recently they were updated, their stars and pull requests. To see an example, check out the forks of GitHub's docs repository.