Skip to content

Block potentially destructive Git pushes

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.

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