Subscribe to all Changelog 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

GitHub's Advisory Database now supports listing malware advisories. You can see them by searching "type:malware" on

If you have enabled Dependabot alerts on your repositories, GitHub will send Dependabot alerts for malware automatically. Note that Dependabot does not send update pull requests for malware as the only resolution is to delete the package and find an alternative.

See more

This beta feature allows repository admins to block Git pushes to a repository when they are potentially destructive.

Developers have had branches deleted from their repository when someone pushes changes with Git's --mirror option. The --mirror option is potentially destructive because it makes the remote repository exactly match the local clone. When run by accident, if the remote has more branches or different data than the local clone, many branch deletes and force-pushes can happen at the remote without any warning. This is often embarrassing for the one who pushed and a big challenge to recover from. Here's a real-world example: git push origin –mirror deleted all of my colleagues' branches.

This destructive situation can usually be identified by multiple branch or tag updates being pushed at the same time. The new beta feature being announced here allows admins to block potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. This can prevent or limit the loss of data.

To use this beta feature, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Limit how many branches and tags can be updated in a single push as shown below. Set the number appropriately for your needs. We recommend the default maximum of 5 branch or tag updates allowed in one push. The minimum value is 2 since two branch updates are required by Git to rename a branch in a single push: delete branch and create branch. Lower numbers are more restrictive of which pushes are allowed, and higher numbers are less restrictive but have more potential for being destructive. As part of this feature's beta, we'd like to learn which number works best for you.

Image showing the setting labeled "Limit how many branches and tags can be updated in a single push."

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

The Dependency Review GitHub Action, which checks if pull requests introduce a dependency with a known vulnerability, now supports configuration based on vulnerability severity and license type.

The following configuration options are available:

  • fail-on-severity: the action will fail on any pull requests that introduce vulnerabilities of the specified severity level or higher
  • allow-licenses: the action will fail on pull requests that introduce dependencies with licenses that do not match the list
  • deny-licenses: the action will fail on pull requests that introduce dependencies with licenses that match the list

The action is available for all public repositories, as well as private repositories that have Github Advanced Security licensed.

Learn more about dependency review enforcement.
Learn more about configuring the Dependency Review GitHub Action.

See more

Back in March, we introduced a new "For you" feed in Public Beta, to help you discover interesting projects across GitHub. Today, we are sharing a few updates to this beta.

  • Users can now filter the feed based on content types: for instance, someone might only want to see announcements and releases on their feed, while another person might want to see everything but releases.
  • Similar events are now grouped (rolled up). For instance, if a person is starring multiple repositories, the feed will display a group of "starred" activities.
  • Feed contents are now paginated.
  • Merged Pull Requests in public repositories will now also be displayed on the feed.

For questions or feedback, visit the GitHub Feed feedback.

See more

Translations are now available for discussion comments in Spanish, Portuguese, Korean, and English. If your first preference browser language is different from the language of the discussion comment, you will now see an option to translate the comment's contents.

Discussion comment in Spanish being translated to English and back again

This feature is in beta and we'd love your feedback. Leave us a note here and let us know what you think.

See more

Teachers we have heard your feedback! The GitHub Classroom team is excited to announce that now in addition to reusing a single assignment you can reuse multiple assignments across Classrooms and/or from semester-to-semester. You no longer have to manually and repeatedly create new assignments using the same template repo.

Using 'Reuse assignment' on the Classroom level you can copy single / multiple assignments and associated template repo across Classrooms and organizations. The copied assignment will include the Assignment details such as name, source repository, autograding and preferred editor.



These changes will be gradually rolling out over the next week. For more information on how to use this new experience, check out our documentation. Your feedback is welcome at our Education Community Forum.

See more

The macOS 12 Actions runner image is now generally available. Start using GitHub Actions to build and publish apps for the Apple ecosystem with the latest version of Xcode by updating your jobs to include runs-on: macos-12

    runs-on: macos-12
      - uses: actions/checkout@v2
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

The macOS 12 Actions runner image has different tools and tool versions than macOS 11. See the full list of changed software.

If you spot any issues with your workflows when using the image, please let us know by creating an issue in the virtual-environments repository.

See more

Workflows triggered by workflow_dispatch and workflow_call can now access their inputs using the inputs context.

Previously workflow_dispatch inputs were in the event payload. This made it difficult for workflow authors who wanted to have one workflow that was both reusable and manually triggered. Now a workflow author can write a single workflow triggered by workflow_dispatch and workflow_call and use the inputs context to access the input values.

For workflows triggered by workflow_dispatch inputs are still available in the github.event.inputs context to maintain compatibility.

Using the inputs context in GitHub Actions

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, we help protect users from data leaks and fraud associated with exposed data.

We have partnered with, a domain redirection service, to scan for their API tokens and help secure our mutual users. Their API keys allow users to create, update, and delete redirects. We'll forward API tokens found in public repositories to, who will notify the user by email and automatically revoke the token. More information about’s API tokens can be found here.

GitHub Advanced Security customers can also scan for API keys and block them from entering their private and public repositories via secret scanning’s push protection feature.

See more

When you visit the GitHub Advisory Database, you can now search for any historical advisory recognized by the National Vulnerability Database.

Previously, we only displayed advisories from our supported ecosystems. We then expanded to have an Unreviewed category for advisories that do not belong to those ecosystems, and we've been auto-publishing new advisories to this category since.

We've now backfilled our database to include all historical advisories from prior years, so you can find any advsiory you may be searching for regardless of publication date. This brings us to over 160 thousand advisories, and counting! You can browse them by clicking the "All unreviewed" button or by searching "type:unreviewed" in the search bar.
Unreviewed advisories backfilled

See more

GitHub Education now provides a safe place for students to take the first step in their open source journey with the launch of Community Exchange on GitHub Global Campus. Community Exchange offers students the ability to connect with peers to learn valuable skills to contribute to open source.


With Community Exchange, users can discover student created repositories and even submit a repository of their own. By submitting a repository a student can:

  • Get exposure for their repository by the nearly two million students on Global Campus
  • Build their portfolio by maintaining or contributing to repositories
  • Help other students learn
  • Grow their network

Community Exchange is available to all Global Campus students on their Global Campus dashboard. Students who haven't joined Global Campus can apply for GitHub Global Campus benefits.

To learn more about Community Exchange, check out our blog post.

See more

GitHub Advanced Security customers can now use sort and direction parameters in the GitHub REST API when retrieving secret scanning alerts. API users can sort based on the alert’s created or updated fields. The new parameters are available at the enterprise, organization, and repository level API endpoints.

Learn more about the secret scanning REST API
Learn more about private repository scanning with Advanced Security

See more

Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface. Also, it is now easier for developers to complete a signoff in the web interface.

Note: Signing off on a commit is different than signing a commit, such as with a GPG key.


The Git command line interface has a --signoff option that developers can use to sign off on their commits. Many open-source organizations require developers to sign off on their changes to affirm compliance with repository rules and licensing. Git's --signoff option appends a specially formatted line to the commit message, as shown here:

Signed-off-by: Mona Lisa <>

This text is what constitutes a signoff. It is often called a “DCO signoff” because the most common signoff agreement is the Developer Certificate of Origin (DCO) from the Linux Foundation.


Open-source projects often use pull request checks to block commits from being merged unless they're signed off. Here’s an example of a commit being blocked in the open-source Gradle Profiler repository, which uses the Probot GitHub App to check whether all of a pull request's commits are signed off:

A pull request check that failed because a commit was not signed off

This problem is more likely when committing from GitHub's web interface where Git’s --signoff option isn't available. To sign off there, developers must manually add the Signed-off-by: text to their commit message. That's easy to overlook or misformat, resulting in the commit being blocked from merging. Resolving this situation can be complicated and slow developers down, as shown in these instructions to fix one commit:

Instructions for amending a commit that is not signed off

In the words of one open-source contributor:

🤦 As a pull request reviewer, this is my biggest pain point. If someone forgets to manually sign off on a commit in the web UI, the pull request check fails and the only resolution is to rebase or squash and force push to fix the commit message. Either way, the review history becomes unclear. This is high friction for new and infrequent contributors and people forget.

New signoff capabilities

Organization owners and repository admins can now require developers to sign off on commits made through GitHub's web interface, such as when editing a file or merging a pull request.

Also, it is now easier for developers to complete a signoff in the web interface, resulting in fewer commits being blocked from merging and less time spent resolving blocked commits.

How to enable required signoffs for an organization

Organization owners can configure an organization-level setting to require sign off on commits made through the web interface. To do so, click Settings in an organization that you are an owner of. Next, in the navigation under Code, planning, and automation, select Repository and then Repository defaults. Finally, under Commit signoff choose All repositories to require sign off on web-based commits in all repositories in the organization, as shown below. Alternatively, select No policy to disable the setting so that sign off will not be required unless enabled at the repository level.

GitHub's organization-level setting for requiring sign off on commits made in the web interface

How to enable required signoffs for a repository

Repository admins can toggle a similar repository-level setting. To do so, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Require contributors to sign off on web-based commits as shown below. This setting will be overridden by the organization-level setting unless the organization has No policy selected.

GitHub's repository-level setting for requiring sign off on commits made in the web interface

When the setting is enabled, the web interface will inform developers that their action of committing will also constitute signing off, as shown below. Like using Git's --signoff option on the command line, signing off in the web interface will automatically append the Signed-off-by: text to the commit message.

GitHub's web interface for committing will inform developers that they are also signing off when they commit

Other information

Related to this feature, GitHub is planning a Git push policy setting that blocks commits from even entering a repository if they are not signed off. This will apply to commits made in GitHub's web interface or pushed from the Git command line or another Git client.

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Custom repository roles are now GA for and Enterprise Server 3.5.

Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.

Custom repository roles can be managed in the Repository roles tab of your Organization settings:


Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.

To get started with custom repository roles, read the docs.

See more

In February 2022, we launched a new feature called community contributions to security advisories.

We have made a handful of changes to the UX based on your feedback:

  • Fixed the breadcrumb on unreviewed advisories to more clearly display they are unreviewed.
  • Hid the link to submit a community contribution when it is not possible due to OSV constraints.
  • Added an information icon clarifying that not all ecosystems are supported.
  • Updated the auto-generated PR title to the format "[GHSA-####-####-####] Advisory Name" to be clearer on which advisory its for.
  • Fixed a bug that was adding unnecessary noise to the PR diff.
  • Added function to auto-post an affirming comment when a contribution is accepted.
  • Learn more about the GitHub Advisory Database
  • Learn more about GitHub community contributions
See more