Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉
You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to the repository network are protected.
Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.
We are rolling out a few minor updates to the user experience for GitHub repositories starting today, in order to be more responsive, performant and more easily accessed by a broader range of users.
Repository Overview:
Go to file: Quickly get to the file you want from the top of every repository using our existing code search and navigation experience.
Special files: If you have Code of Conduct, License, or Security files in your repository, they are now shown in tabs alongside your README.
Branches:
Status checks: At a glance, see the status checks’ details on any branch.
Stale Branches: The overview page for branches no longer defaults to showing stale branches to improve load times. You can still easily see stale branches by clicking the “Stale branches” tab.
Commits:
Filters: New commits filters allow you to sort by users or limit results to specific date ranges.
These changes have been in a feature preview for the past few months and thanks to community insights, we’ve made several improvements that allowed us to now exit the preview, and bring these enhancements to everyone on GitHub. Join the conversation about this release in the community discussion.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
New updates to the branches and commits pages are now in feature preview. These updates are focused on improved navigation, performance, and making these experiences more accessible.
Branches
We added clarity to the list header explaining what each section of the branches page does. Stale branches are now hidden by default to speed up page load times.
Commits
You can now filter commits by a date range and collapse the list per day to find the commits that matter to you quickly.
Click here if you have feedback and let us know in our community discussion.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
When editing a file on github.com, repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now default to creating a new branch instead for directly committing. You can still commit directly to a protected branch, but doing so will add notifications in-line highlighting that some rules will be bypassed.
Historically the default behavior was to push through any branch protections with no notifications they were being bypassed.
Now we recommend creating a branch for admins eligible to bypass branch protection rules. This behavior occurs when adding new files to a repository as well as during pull requests.
Today we are announcing the public beta of repository rules! 🎉
Repository rules are GitHub’s next evolution of branch protections to help make your repositories more secure and compliant at scale.
Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.
Creating rules
At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.
The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.
When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be merged, while disabled rulesets are not enforced; they will not prevent merges but allow admins to craft rules before enforcing them. Enterprise Cloud customers can also evaluate rulesets: a “dry run” mode for understanding the impact of new rules before they are active and enforced.
It’s also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.
Viewing the rules
You can always know what rules are in place for a repository.
Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.
From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.
Getting Started
Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.
We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
We now show bypassed branch protection rules in response to Git pushes. These are information messages and are not designed to block workflows.
Historically there was no indication after a Git push that branch rules had been bypassed.
Repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now see a list of rules that were bypassed.
You can now create a custom role to manage branch protections without having to grant the Admin role. Previously, to manage branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Edit repository rules permission, allowing just the right amount of access.
Organizations and enterprises using branch protections may see false-alert flags in their security log for protected_branch.policy_override and protected_branch.rejected_ref_update events between January 6 and January 11, 2023.
These events were improperly emitted due to a change in the underlying logic that checks if branch protection criteria have been met.
No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts.
Require approval from someone other than the last pusher
Now, before a pull request can be merged, you can require it to be approved by someone other than the last pusher.
Meaning, the most recent user to push their changes will need a pull request approval regardless of the Require approvals branch protection. Or in the case of 1 approval required, someone other than the last user to push their changes will also need to approve. If the approvals come from other folks than the last pusher, those two approvals will be sufficient.
Lock branch
This allows for branches to be locked, prohibiting changes. You can lock a branch allowing you to have a maintenance window and prevent changes, or to protect a fork so it only receives changes from its upstream repository.
To use this feature in a branch protection rule, enable Lock branch.
We updated the web UI to make keeping forks in sync with their upstream repositories more intuitive. "Fetch upstream" has been renamed to "Sync fork," which better describes the button's behavior. If the sync causes a conflict, the web UI prompts users to contribute their changes to the upstream, discard their changes, or resolve the conflict.
You can now create a custom role to bypass branch protections without having to grant the Admin role. Previously, to bypass branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Bypass branch protections permission, allowing just the right amount of access.
To enforce branch protections for all Admins and roles with the "Bypass branch protections" permission, enable Do not allow bypassing the above settings in your branch protection rules.
This permission differs from the Push commits to protected branches permission, which allows pushing to a protected branch, but branch protection rules will still apply and could result in a push being denied.
Previously, when creating a fork all branches from the parent repository were copied to the new fork repository. There are several scenarios where this is unneeded, such as contributing to open-source projects. When all branches are copied, it could result in slow repo cloning and unnecessary disk usage. With this new feature, only the default branch is copied; no other branches or tags. This may result in faster clones because only reachable objects will be pulled down.
If you want to copy additional branches from the parent repository, you can do so from the Branches page.
Previously, it was difficult to create a new branch from the GitHub UI. Now you can create a branch on the Branches overview page. Just click the New branch button, shown here:
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:
