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.

Learn more about push rules in our documentation and join the community discussion to leave feedback.

The post Push rules public beta appeared first on The GitHub Blog.

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.

The post Updates to repository pages appeared first on The GitHub Blog.

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.

The post New branches and commits pages – feature preview appeared first on The GitHub Blog.

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.

We appreciate your feedback in GitHub's public feedback discussions

The post Enhancements for admins bypassing branch protections on github.com appeared first on The GitHub Blog.

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.

The post Introducing Repository Rules Public Beta appeared first on The GitHub Blog.

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.

We appreciate your feedback in GitHub's public feedback discussions

The post Info messages for bypassing branch protections in Git appeared first on The GitHub Blog.

This permission grants the ability to create, edit, and delete both branch protection rules and protected tags.

For more information, visit Managing custom repository roles for an organization in the GitHub documentation.

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

The post Manage branch protection rules with a new permission appeared first on The GitHub Blog.

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.

• Read more about GitHub's audit logging
• Read more about protected branches

The post False-alert flags will appear in audit logs due to a bug in branch protections appeared first on The GitHub Blog.

The GraphQL API supports:

• Creating a branch linked to an issue
• Removing the link between a branch and an issue
• A linkedBranches field on the Issue Object

The post GraphQL APIs for creating a branch linked to an issue appeared first on The GitHub Blog.

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.

For more information, read About protected branches in the GitHub documentation.

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

The post New Branch Protections: Last Pusher and Locked Branch appeared first on The GitHub Blog.