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

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

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

GitHub will now verify Git commit signatures and show commits as "Verified" even if their public GPG signing keys are expired or revoked (but not compromised). You can also upload GPG keys that are expired or revoked to your GitHub user profile.

Using GPG or S/MIME, you can sign Git commits. These commits are marked "Verified" in GitHub's web interface, giving others confidence that they come from a trusted source because they carry their committer's signature.

GPG keys often expire or are revoked when no longer used. Previously, when a public GPG key stored in a GitHub user profile was expired or revoked, all commits that had ever been signed with that key would be shown as "Unverified" on GitHub. That raised unnecessary concern since the commits were validly signed before their key was expired or revoked. Now, when a user's GPG key expires or is revoked for a reason other than being compromised, GitHub will continue showing commits that were previously signed with that key as "Verified." You can also upload GPG keys that are expired or revoked. Besides maintaining trust in commits’ sources, this allows GPG keys to be added or rotated for greater security without losing the “Verified” status of previously signed commits.

An image of GitHub showing a commit's signature as verified even though its public GPG key is expired

For more information, visit About commit signature verification in the GitHub documentation.

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

See more

We’ve made it easier to discover multiple licenses within an open source repository. First, navigate to the **About** sidebar on the repository page to see if the repository contains any licenses. If it does, they’ll be listed underneath the README file.


If only one license is detected, the link will take you directly to that license file. If more than one license is present, click on the list of licenses to display a dialog containing all of the licenses available at the root level of the repository. Then you can select from the dialog which license you’d like to navigate to.


With the use of an open source Ruby gem called Licensee, we detect license files and compare them to a short list of known licenses. Learn more about how repositories on GitHub are licensed.

Adding an open source license to your repository ensures that others can use, copy, modify and contribute back to your project. If your repository doesn’t have an open source license and you want others to get involved, you can learn more about adding one here. The dialog will match any top-level licenses with a variation of LICENSE, COPYING, OFL and PATENTS, including file extensions (i.e. LICENSE-MIT, LICENSE-GPL).

See more

Previously, some branch protections only allowed exceptions to be granted to users and teams. Now, GitHub Apps can also be granted exceptions to any branch protection that supports exceptions.

Admins can create branch protection rules to enforce certain workflows for branches, such as requiring a pull request before changes can be merged to a branch. This is a good practice, but you may want to make exceptions to a rule for specific people, teams, or GitHub Apps. For example, if you have a GitHub App that calls GitHub APIs to make changes in a repository, you may want to permit that App to make changes without creating a pull request. Previously, these exceptions could be granted to people and teams, but only some protections allowed GitHub Apps.

Now, branch protections that previously only allowed exceptions for people and teams also support GitHub Apps. When admins configure these branch protections, they can choose from a list of GitHub Apps that are installed and authorized for the repository, as shown here:

Image of adding a GitHub App as an exception to a branch protection setting

For information about branch protection rules, visit Managing a branch protection rule.

For information about GitHub Apps, visit About GitHub Apps.

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

See more

We've added an enhancement to the repository view for a branch that is different than its upstream branch. Previously we showed the number of commits the branch was ahead or behind the upstream, but there wasn't an easy way to show the differences. Now you can click a link that takes you to a comparison page to see the differences.


Note: there is a different link for ahead versus behind

  • ahead represents changes your branch has but the upstream branch does not
  • behind represents changes the upstream branch has but your branch does not

Read more about branches.

See more

Previously, the Get repository content REST API endpoint had a file size limit of 1 MB. That didn’t correspond to the Create or update file contents endpoint which has a file size limit of 100 MB. Now, both endpoints have a file size limit of 100 MB. However, requests for file contents larger than 1 MB must include the .raw custom media type in the Accept HTTP header, as shown here:

Accept: application/vnd.github.v3.raw

Read more about GitHub's REST API endpoints for repository contents.

See more

Now organization admins can pin a repository to their public or member-facing organization profiles directly from the repository page with the new pin repository dropdown. Public repositories will be pinned to public org profiles, where as public, private and internal repositories can be pinned to the member-facing organization profile. Learn more about organization profile updates here.

pin repos dropdown gif

See more

tortenfabrik-relaode_final!-Apple ProRes 422 HQ 2022-04-20 17_18_03

Now you can customize your organization's Overview page to show content dedicated to public users or members of the organization. A new member view is only visible to members of the organization and can be controlled in the sidebar to toggle between public and member view.

A README only visible to members

Similar to the public organization README that we released last year, you can now create a README that is only visible to members of your organization. In the .github-private repository the /profile/ will be displayed on your organization's Overview page.

Pinned private repositories

Organization owners are able to define a set of six public, private or internal repositories that are only visible to members of their organization, enabling members to quickly access popular or frequented repositories.

For more information about the new features, see "Customizing your organization's profile".

See more

Previously, GitHub's web UI did not allow deleting a branch that was associated with an open pull request. Now you can delete such a branch from the UI. However, doing so will close all open pull requests associated with the branch. Before the branch is deleted, you must confirm that the pull requests may be closed.

Confirm deleting a branch

Read more about working with branches.

Read more about collaborating with pull requests.

See more

Repository owners can now configure tag protection rules to protect tags in all public repositories and in private repositories on the Pro, Teams or Enterprise plans on GitHub. Once protected by a tag protection rule, tags matching specified patterns can only be created and deleted by users with "Maintain" or "Admin" permissions to the repository. For more information, see our documentation.


See more

Users can now unsubscribe from all repositories owned by a given user or organization. Navigate to to find a list of the repositories that you are subscribed to. The Unwatch All button gives you the option to unsubscribe from all repositories, or just the ones that belong to a specific user or owner. It will appear when you are watching all activity or custom notifications on over 10 repositories.

dropdown with filter

Clicking any of the dropdown options opens a modal to confirm unwatching repositories owned by the selected user/organization (or all repositories).


You can read more about how to unwatch a single or multiple repositories in the 'Managing your subscriptions' documentation

See more

Appending ?plain=1 to the url for any Markdown file will now display the file without rendering. As with other code files, it will also show line numbers, and can be used to link other users to a specific line or lines. For example, appending ?plain=1#L52 will highlight line 52 of a plain text Markdown file.

See more