pushes

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

We've now made it easier to understand changes to your repositories with the new activity view. Historically viewing pushes to a repository required contacting GitHub support. This new activity view gives users with read access the ability to self-serve insights to a repository and all of its changes.

You can access the Activity view from the main page of a repository by clicking "Activity" to the right of the list of files.

Location of activity view link on repo homepage

You can also access the activity view from the Branches page of any repository by clicking on the activity icon.

Branch activity icon

Activity view

From the activity view you can sort and filter to find exactly what you are looking for.

Filter activity type

Here is an example of how you could use the activity view to find a force push on a particular branch, and then compare the changes to the repository before and after the push:
Screen recording of the activity view

Learn more about the Activity view.

Already using the activity view? We'd love to hear your feedback.

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