Skip to content


Subscribe to all “repositories” 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

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

Configuring merge queue in your repo rulesets is now available in public beta!

Screenshot showing the configuration of merge queue inside a ruleset

Merge queue & rule insights

Until now, rule insights would only list one pull request as merged even when multiple pull requests were merged by the queue at the same time. Also in this beta, each pull request in a merge queue will have an individual record in rule insights, linked to the actor that added the pull request to the merge queue.

Example screenshot showing rules insights and all PRs from a queue

Within the additional data of a rule insight dialog you can now see all the pull requests that merged in the same group along with the checks needed for the queue.

Example screenshot of details of a queue in rule insights


  • The merge queue rule cannot be configured via an API. This feature will be available in the near future.
  • Merge Queue for branch protections and repository rules do not support wildcard patterns
  • Not supported in organization rulesets.
  • Multiple merge queues configured against a single branch will prevent merging.

Join the discussion within GitHub Community.

See more

repository custom properties banner image

We’re excited to announce the general availability of Repository Custom Properties, a major enhancement to how repositories are managed and classified across GitHub organizations.

Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets.

Check out this video from our own Jon Peck for a walk through of a common scenario.

New organization repositories list public beta

Starting today the new repositories list view moves to public beta.

Improvements to Repository Rulesets

Repository Rules now support adding Dependabot to bypass lists. This enables you to let Dependabot merge changes to a repository’s protected branch.

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

Head over to community discussions for feedback.

See more

Starting today, in Actions workflows, the pull_request_target trigger is now supported for repository rulesets that require a successful workflow run. This is in addition to pull_request and merge_group, making pull_request_target the third workflow trigger supported by repository rulesets.

Read our recent general availability announcement to learn more about how organizations can set up policies with repository rules that require a successful workflow run before code can be merged into its repositories.

Learn more in our repository rulesets documentation and don’t forget to ask questions or leave feedback in the community discussion.

See more

There are two new metrics available under the Repository object in the GraphQL API:

  • LastContributionDate – The most recent date there was any of the following activity: a commit to a repository’s default branch, opening an issue or discussion, answering a discussion, proposing a pull request, or submitting a pull request review. This is a good single-number metric to find projects that may be unmaintained or in need of archiving.
  • CommitCount – A monotonically increasing count of the total number of commits pushed to the default branch of the repository. Tracking the change in this over time will give a sense of the overall activity in the repository.

These metrics are currently in public beta, so you will need to include a header to your GraphQL requests to opt-in:

GraphQL-Features: ospo_metrics_api

Additional documentation and context around these metrics is available in the github-ospo repo. Please provide your feedback on this discussion thread:

See more

New updates to the branches and commits pages are now in feature preview. These updates are focused on improved navigation, performance, and making these experiences more accessible.


Screenshot showing new branches page on GitHub Docs Repository

We added clarity to the list header explaining what each section of the branches page does. Stale branches are now hidden by default to speed up page load times.

GIF walkthrough of branches page showing the new UI and clicking on various elements to show new functionality.


Screen shot showing new commits page on GitHub Docs Repository

You can now filter commits by a date range and collapse the list per day to find the commits that matter to you quickly.

GIF showing the commits page filtering by date in a calendar and collapsing commits for a whole day

Click here if you have feedback and let us know in our community discussion.

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.


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!
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{owner}/{repo}/rulesets/rule-suites

Specific insight rule suite for a repository ruleset
–  GET{owner}/{repo}/rulesets/rule-suites/{rule _suite_id}

Organization Endpoint

All org insight activity
–  GET{org}/rulesets/rule-suites

Specific insight rule suite for an organization ruleset
–  GET{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

On September 27, 2023, we began blocking npm package publishes with differing name or version fields between the manifest and tarball package.json. This blocking protects against obfuscation. The different fields in the manifests have been assessed from a risk-based perspective. We will continue to analyze for other mismatches that can be blocked that won’t have adverse effects on the ecosystem. If a package is blocked, a user may receive an error message similar to “Package ‘version’ is “1.0.4”. It should match “1.0.3” from “package.json” in packaged tarball. Make all changes to package.json before packaging a tarball to publish.” In addition, a new tool, npm pkg fix, can help users fix any validation errors from the registry when they attempt to publish a package.

See more

Announcing changes to permissions for packages.

We are restricting the refs REST API endpoint from accepting POSTs from users and apps that only have the permission to read and write packages. Previously, this endpoint accepted updates to both tags and branches.

If that ability is critical to your development flows you will now be required to add explicit contents permissions to create refs.

A small cohort of customers relying on this flow have been notified of these changes and will have additional time to remediate.

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

See more

Building on the Public Beta of organization archiving, we're excited to announce that organization archiving is now generally available.

You can now archive all repositories in an organization with a single click. Archiving an organization will:

  • Archive all repositories in the organization
  • Set a key in the API to indicate the org has been archived
  • Restrict activities in that organization such as creating new repos
  • Display a banner on the organization's profile indicating that it's been archived
  • Email the organization's owners to let them know that the organization has been archived

To archive an organization, go to the organization's settings page and click the "Archive organization" button in the Danger Zone. This will launch a background job which performs the archiving; once complete, the banner will show up on the organization's profile page.

For more information on organization archiving, including how to un-archive an organization, see "Archiving an organization"

We'd love to hear your feedback on how it works for you.

See more

Repository rules are now generally available on

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

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 To access the new code search experience, and make full use of the symbol navigation, create an account or log in to

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

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:


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