repositories

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

Persistent commit signature verification is generally available

We’re excited to announce that persistent commit signature verification is now generally available! This powerful feature ensures that commit signatures are verified once at the time of the push and remain permanently verified within their respective repository’s network.

With persistent commit signature verification, commit signatures retain their verified status even if signing keys are rotated, revoked, or contributors leave the organization. You can view verification timestamps by hovering over the Verified badge on GitHub or by accessing the verified_at field through the REST API.

A badge tooltip displaying the date when the signature was first verified.

This feature brings long-term reliability to your commit history, offering a consistent solution for managing commit signatures over time. New commits have had persistent records since the public preview launch. Existing commits progressively gain persistent records during their next verification, such as when viewing the Verified badge on GitHub or retrieving the commit via the REST API.

Learn more about commit signature verification and join the conversation in the GitHub Community.

See more

Pull request merge method rule – Public Preview

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.

Screenshot of merge type rule selection

Learn more in the documentation and join the discussion within GitHub Community.

See more

Enterprise repository properties, policies and rulesets – Public Preview

We are excited to announce the launch of new governance at scale features for enterprise accounts in public preview. This preview includes enterprise custom repository properties, enterprise repository policies and enterprise rulesets to help enterprise administrators manage more at greater scale.

Check out this video on managing your repositories at scale across the enterprise and learn more below.

Enterprise custom properties

Enterprise customers can now enrich repositories with metadata and govern protections for branches, pushes, and tags across your entire enterprise using repository custom properties and rulesets.

Enterprise custom properties screenshot
With custom properties available at the enterprise level, you can ensure consistent properties across organizations without manual synchronization and de-duplication. Enterprise and organization properties share a common namespace to prevent confusion when searching or targeting rulesets with properties.
To learn more about enterprise custom properties, head over to the docs.

Enterprise rulesets

Enterprise rulesets screenshot

Enterprise-level rulesets enforce consistent code governance rules to ensure thorough reviews of critical repositories with pull requests, and protect important locations from unauthorized pushes. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.

Enterprise repository policy

We are also introducing repository policies, which allow you to effectively manage repository lifecycle events such as deletions and visibility from the enterprise level. Enterprise administrators can target enterprise polices over repositories in organizations, as well as repositories homed under personal namespaces for any company using enterprise managed users.

Enterprise repository policy screenshot
Repository policies extend the ruleset framework to help you govern repositories beyond the code itself. These policies manage lifecycle events, enhancing the security, compliance and resilience of your repositories. You can enable repository policies per organization, and the preview launches with five policies:
– Restrict visibility
– Restrict creations
– Restrict deletions
– Restrict transfers
– Restrict names

To learn more about enterprise repository policy, head over to the docs.

Feedback

To ask questions or share feedback, join our discussion in the GitHub Community.

See more

Persistent commit signature verification now in public preview

We’re excited to introduce persistent commit signature verification, a powerful new feature designed to elevate the security and reliability of your repository’s commit history.

Starting today, GitHub verifies commit signatures when they are first pushed, and once a commit’s signature is verified, it remains verified within its repository’s network. This supports organizations in maintaining a secure and accurate record of contributions without constantly rechecking the validity of every signature. You can view these persistent verifications directly on GitHub, where a quick hover over the Verified badge displays the timestamp of the original verification.

Efficient, Secure, and Transparent Verification

Previously, commit signatures were verified on demand, via a process that was not performant and had risks of previously verified signatures becoming “unverified” due to various reasons like service outages or key rotations.

Persistent commit signature verification solves these issues by validating signatures at the time of the commit and storing the verification details permanently. This also brings consistency to the commit history as git commits are immutable and they do not natively support key rotation.

Managing commit signatures can be a challenge, but persistent records ensures that verified commits remain verified over time, even if signing keys are rotated, revoked, or contributors leave the organization.

How to tell if the verification has a persistent record?

When a commit’s signature is verified upon being pushed to GitHub, the verification record is stored alongside the commit. This record is immutable, ensuring that the verified status is maintained permanently.

You can view the verification timestamp by hovering over the Verified badge on GitHub or via the GitHub REST API which now includes a verified_at field.

Learn more about commit signature verification on GitHub.

Designed for Real-World Key Rotation and Contributor Management

For organizations managing signature verification – whether GPG, SSH, or X.509 keys using S/MIME – persistent commit signature verification provides a robust way to ensure signature integrity across the board. Now, any commit with a verified status can retain that status, even when the signing key is rotated or removed.

Persistent commit signature verification is applied to new commits only. For commits pushed prior to this update, persistent records will be created upon the next verification, which happens when viewing a signed commit on GitHub anywhere the verified badge is displayed, or retrieving a signed commit via the REST API. This ensures that your repository remains secure while providing flexibility in managing your verification practices.

This approach lays the groundwork for future improvements aimed at enhancing repository integrity and authenticity of contributions within GitHub.

Key Management Caveat: Revocation and Expiration

Persistent commit signature verification ensures that verified commits retain their status indefinitely, it’s important to note this records the state of the signature at the time of the commit. If a signing key is later revoked, expired, or otherwise changed, GitHub will not re-verify previously signed commits or retroactively modify the verification status.

For organizations using S/MIME keys, this does introduce a minor change: revoked S/MIME keys will not verify new commits or those without an existing persistent record. Since git commits are immutable, persistent commit signature verification aligns with this concept by maintaining the original verification status without change. Organizations may need to manage key states directly to align with their security policies, especially in cases involving frequent key rotation or revocation.

This approach ensures that once a commit is verified, it remains trusted based on the record at the time, bringing consistency and long-term reliability to your commit history.

Moving Towards a Future with Secure and Authentic Contributions

With this launch, we’re addressing a key issue: commit verification that isn’t fragile or temporary. Teams can now implement signing key policies, without worrying about losing the verified status of past work.

Stay tuned for more updates as we continue to enhance commit verification. If you have feedback or suggestions, please let us know through our GitHub Discussions forum.

See more

Repository deploy keys are controlled by enterprise and organization policy [GA]

GitHub Enterprise Cloud enterprise and organization administrators can now configure policies to restrict the usage of deploy keys across all the repositories of their organizations, giving you more control and greater security over your deploy keys.

Deploy keys provide SSH access to a single repository and are often used by integrations with external servers to a repository without using a personal GitHub account. However, this makes it hard to track the lifecycle of deploy keys across your repositories, as they exist outside of a user context and have no timed expiration capability. Now with the ability to set deploy key policies, you can more easily track and manage your deploy keys across your repositories.

All new enterprises and organizations will have the deploy key policy disabled by default.

For compatibility reasons, the deploy key policy will be enabled by default for all existing enterprises and organizations. You may want to explicitly disable the setting after evaluating and replace your deploy key usage with more secure alternatives like GitHub Apps.

For more details, learn more about the new policy for managing deploy keys.

See more

Updates to repository enterprise policy, ruleset and custom properties

Recent improvements to enterprise repository policy, rulesets, and custom properties now ensure a more consistent, intuitive experience, making it easier for you to navigate and accomplish your tasks efficiently.

  • Enterprise repository policy page has been renamed to “Member privileges” to align the page title with the current URL path, API endpoints and the corresponding organization setting.

Screenshot of member privileges

  • Repository rulesets now support enterprise owners as a bypass actor, ensuring your most privileged roles across your enterprise can bypass rulesets.

Screenshot of ruleset bypass with enterprise owners

Screenshot of additional repository property section

We want to hear from you

Questions or suggestions? Join the conversation in the community discussion.

See more

New commit details page (public beta)

A new version of the commit details page is now available in public beta!

This new page, which is enabled by default, lets you quickly understand and navigate the changes in a commit with improvements to filtering, commenting, and keyboard navigation.

Screen shot of the new commit details page that shows the metadata about the commit, a file tree showing the 3 files changed by the commit, diff snippets for each of the changed files, and a floating comment

What’s new 🎉

Here are a few of the noteworthy changes:

  • Floating comments: Code comments float over the diff when selected. To select, click on the commenter’s avatar to the right of the line.
  • Comment counts: To help you identify files with comments, the number of comments for a file now appears in the file tree.
  • Keyboard navigation within diffs: You can now navigate around changed lines in the diff using the up and down keys on your keyboard. A new context menu also makes it easier to comment, copy, and select.
  • Quick view switching: Switching between unified and split views no longer reloads the page.
  • Filter by file extension: Easily filter changed files by file extension in the diff to see the content most relevant to you.
  • Filtered out diffs hidden: When filtering the file tree, diffs are filtered as well, allowing you to reduce distraction and see the files you care about most.

Next steps 📣

To give feedback, ask questions, or report a bug join us in the feedback discussion.

To opt out of the preview, go the Feature Preview dialog on your profile, select New Commit Details Page, and click Disable.

To learn more about viewing commits, see About commits.

See more

Push Rules are now generally available, and updates to custom properties

You can now restrict pushes into your private and internal repositories and their forks, with push rules – a new type of ruleset. Push rules enable you to limit updates to sensitive files like actions workflows, and help to enforce code hygiene by keeping unwanted objects out of your repositories.

In addition, organization owners can now allow repository property values to be set when repositories are created. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories.

Push Rules

Organization and repository owners can now configure rules that govern what changes can be pushed to their repository, by attributes of the files changed – including their paths, extensions and sizes.

Screenshot showing the list of new push rules with options configured

Available push rules

  • Restrict file paths
    • This rule allows you to define files or file paths that cannot be pushed to. An example of when you might use this is if you wanted to limit changes to your Actions workflows in .github/workflows/**/*
  • Restrict file path length
    • You can limit the path length of folder and file names.
  • Restrict file extensions
    • You can keep binaries out of your repositories using this rule. By adding a list of extensions, you can exclude exe jar and more from entering the repository.
  • Restrict file size
    • Limit the size of files allowed to be pushed. Note: current GitHub limits are still enforced.

Push rules are available on GitHub Team plans for private repositories, and coverage extends to not just the repository, but also all forks of that repository. Additionally, GitHub Enterprise Cloud customers can set push rules on internal repositories and across organizations with custom repository properties. You can also access rule insights to see how push rules are applied across your repositories.

Additional details

  • Delegated bypass for push rules, currently in beta, allows your development teams to stay compliant with internal policies and keep a clean git history. Developers can easily request exceptions to push rules, that are reviewed and audited all within GitHub.
  • To ensure best performance push rules are designed to handle up to 1000 reference updates for branches and tags per push.

For more information, see the Push Rule documentation and to get started you can visit the ruleset-recipes repository to import an example push ruleset.

Custom properties

Organization owners can now allow their users to set custom properties during repository creation. Previously, this was only available to repository administrators or those with permissions to edit custom repository properties. By selecting Allow repository actors to set this property for your custom property, you can ensure repositories have properties attached from the start.

Screenshot of new repo being set up with a custom repository property

We want to hear from you

Questions or suggestions? Join the conversation in the community discussion.

See more

Retrieve the code security configuration currently applied to a repository via API

You can now retrieve the code security configuration applied to a specific repository via the repos endpoint in the REST API. Previously, you could only retrieve all the repositories associated with a configuration rather than the inverse.

Code security configurations help you manage and enforce the enablement of your security features like Dependabot, code scanning, and secret scanning.

To learn more about retrieving code security configurations with our repository REST API endpoint, check out our docs here.

See more

Enhanced Repo Insights Views

New Enhanced Repo Insights Views

We’re thrilled to introduce improvements to Repo Insights! With this update, you’ll find significant enhancements to two of our repository insights views—Contributors and Code Frequency. Both now utilize an SVG-based solution, offering improved focus navigation for precise, point-by-point interaction. You can also hide a series by interacting with the chart legend and view or download the data in both table format and as PNGs. Let’s dive into the details!

Contributors

  • Date Range Filter: While the click-and-drag date range selection was a handy feature, it was also a hidden feature. The new date range filter is always visible and fully navigable by keyboard, making it more accessible and easier to use.

  • Clear Date Range Display: The current date range is now explicitly listed under the heading, giving you a clear and immediate understanding of the data timeframe.

  • Responsive Contributor Cards: Previously locked to a two-column view, contributor cards are now more responsive on small screens, seamlessly wrapping to a single-column layout for a better viewing experience.

Code Frequency

  • Enhanced Axes Differentiation: The two different axes are now distinguished not just by color but also by line style, making it easier to interpret the data at a glance.

  • Detailed Tooltips: Data points are now navigable and display more details in a tooltip. Previously, you could only visually reference data against the axes. Now, you get more information directly from the chart itself.

Explore the new features and let us know what you think! Join the discussion within the GitHub Community.

To revert this update, click on your profile picture in the top right corner of the page, go to the feature preview menu, select “Enhanced Repo Insights Views” and click disable. If you choose to turn this feature off – please let us know why using the link listed above!

 

See more

Repository updates July 31st 2024

We’re excited to bring an updated repository list view experience and the ruleset merge queue rule to general availability, as well as an update to the status check and workflow rules.

Finding repositories in your organization is now easier

With the introduction of custom properties earlier this year we wanted to make it easier to find repositories across your organization. With the new organization repository view and advanced filtering you find repositories based on common parameters like visibility and language, but also custom properties, size, license and a host of additional values.

Screenshot of repository list view filtered by visibility, archived status and a custom property showing a list of 64 repositories.

Repository Rules updates

Repository ruleset merge queue rule is now generally available

In addition to being able to manage your merge queue via rules, you can now see all the pull requests that merged in the same group along with the checks needed for the queue with rule insights.

Screenshot of repository rule merge queue options with default configurations.

Learn more about merge queues in our documentation and repository rules REST API

Avoid required status checks and required workflows when creating branches

Applying status check and actions workflow rules to newly created branches has been a point of friction in rulesets. When creating a new branch will fail unless you add bypass actors or create an intermediate unprotected branch. To alleviate this friction there is a new option available prevent checks and workflows from running on new branches.

Screenshot of require status check rule with the new "Do not require status checks on creation" option enabled

Learn more about status check rules and required workflows rules in our documentation.

Join the discussion within GitHub Community.

See more

GitHub Private Mirrors App – Public Beta

Today, we’re releasing a beta version of an open source GitHub App that manages private mirrors of public upstream repositories. The Private Mirrors App (PMA) enables organizations with regulatory or policy code review requirements to conduct their reviews in private, before contributing changes upstream. The app manages the lifecycle and synchronization of these private mirrors and automatically configures rulesets to manage PRs made to the mirrors.

The main benefits of working on private mirrors through PMA are:

  • Branch protection rules can enforce PR reviews by people on particular teams to ensure proper signoffs
  • If commits include code/keys/docs that should not be made public, there’s the opportunity to remove them and squash merge without leaking history
  • Initial development can happen inside an Enterprise Managed Users (EMU) organization, whose users ordinarily can’t interact with public GitHub repos. Once the app syncs a change, the public fork and upstream PR use normal github.com identities.

If this is interesting to you, check out the Private Mirrors App repo. If you’ve got questions or feedback, feel free to file an issue in the repostitory or join the conversation in the GitHub Community Discussions.

See more

Repository updates June 12th 2024

We’re excited to introduce enhancements to custom properties as well as updates to the push rule public beta.

Custom properties updates!

New property types

  • Multi select allows a repo to have more than one value for a property defined. Now a repository can have a property that defines a compliance requirement with values for FedRamp and SOC2, for example.
  • True/False allows you to set whether a given property is true or false for a given repository.

repository properties with multi select

Target rulesets by repository visibility and more

In addition to targeting repositories with the custom properties you’ve created, we’ve now extended property targeting to include the ability to target by:
– Visibility: public, private, or internal
– Fork: true, false
– Language: select primary repository language.

System property targeting in a ruleset screenshot

Learn more in the custom properties documentation

What do you think? Start a discussion within GitHub Community.

Push rule delegated bypass public beta!

We are expanding on the push rule public beta with a new delegated bypass flow.

Previously to bypass push rules you had to be on the bypass list to push restricted content. Now with delegated bypass, contributors can propose bypassing a push rule and members of the bypass list can review those bypass requests to allow or deny the content.

Learn more about push rule delegated bypass in the repository rules documentation and join the push rule discussion in the GitHub Community.

Delegated bypass screenshot

See more

Sunset Notice – Tag Protections

EDIT: Monday December 2nd, 2024

GitHub Enterprise Server Timeline changing sunset to GHES 3.17 as the final version instead of 3.16.

Starting today, we will begin work towards the sunset of tag protections, with a full deprecation planned for August 30, 2024. See below for a full sunset timeline. You can migrate existing tag protections with the import to ruleset feature.

We launched repository rules last year to meet the needs of tag protection rules, while also scaling support to provide new functionalities like org-wide rules, granular restrictions for creating, reading, and updating events, and a more granular bypass model that does not require repository administrator permissions. As we such, we will sunset tag protections in favor of our ongoing investment in the repository rulesets platform.

You can import existing tag protection rules today with the existing migration feature. If no action is taken before the sunset date, GitHub will migrate all existing tag protections into a corresponding ruleset.

When are changes happening?

GitHub.com Timeline

  • May 30 : Repositories without tag protection rules will no longer be able to add new protection rules via the GitHub.com UI
  • July 24 through August 14 : A series of API brownouts will be run, see below for additional details on dates and times.
  • August 30, 2024: All tag protection rules will be migrated to a new tag ruleset. All REST and GraphQL API endpoints will be deprecated

GitHub.com API Timeline

  • May 30: API responses will include a deprecation notice
  • July 24: 1 hour API brownout
  • August 7: 8 hour API brownout
  • August 14: 24 hour API brownout
  • August 30: The tag protection rule API will begin responding with NULL data
  • The tag protection rules API will be deprecated in the next calendar version

GitHub Enterprise Server Timeline

  • Version 3.14: Tag protection rules will be marked for deprecation with an in-product banner and API responses will include a deprecation notice
  • Version 3.15: No changes will be made
  • Version 3.16: No changes will be made
  • Version 3.17: Tag protection rules will be migrated to a ruleset and the tag protection rule feature will no longer be available

 

Join the discussion within GitHub Community.

See more

[Public Beta] Repository collaborators for Enterprise Managed Users

Enterprise Managed Users can now be added directly to a repository in their enterprise as a collaborator, without becoming a member of the organization. These users function like outside collaborators, with a few differences:
1. Only user accounts from within the enterprise can be added to the repository. This means that users you want to collaborate with must still come from your linked identity provider (IDP).
2. EMU users can only be collaborators on repositories in their enterprise. EMU accounts cannot collaborate outside their enterprise.
3. Repo Collaborator invitations can only be sent by an EMU’s enterprise owner by default, while in non-EMU enterprises and organizations both enterprise and organization owners can manage outside collaborators.

Like outside collaborators – users do not have to SSO authorize their credentials in order to access repositories that they have been granted access to as a repository collaborators. This aligns to the current access model for internal repositories on GitHub.

You can try out repository collaborators by going to the repository policies section of your Enterprise settings and selecting which tiers of administrators are allowed to invite collaborators.

For more information about repository and outside collaborators, see “Roles in an organization“.

See more
View more changes