Skip to content

branches

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

Push rules public beta

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. 🎉

A glimpse of push rules in action

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.

See more

Updates to repository pages

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:
Screenshot of repository overview page showing entering a letter to expand to go to file menu.

  • 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:
Screenshot of branches page showing the overview tab for branches of GitHub Docs repos.

  • 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:
Screenshot of Commits page filtered by date and user.

  • 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.

See more

New branches and commits pages – feature preview

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

Screenshot showing new branches page on GitHub Docs Repository

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.

GIF walkthrough of branches page showing the new UI and clicking on various elements to show new functionality.

Commits

Screen shot showing new commits page on GitHub Docs Repository

You can now filter commits by a date range and collapse the list per day to find the commits that matter to you quickly.

GIF showing the commits page filtering by date in a calendar and collapsing commits for a whole day

Click here if you have feedback and let us know in our community discussion.

See more

Enhancements for admins bypassing branch protections on github.com

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.

Screenshot of commiting directly to a repository
Screenshot of bypassing rules in a PR>

We appreciate your feedback in GitHub's public feedback discussions

See more

Introducing Repository Rules Public Beta

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.

Screenshot of ruleset overview

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

Screenshot of creating a ruleset

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.

Screenshot of read only view of rules

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.

See more

Info messages for bypassing branch protections in Git

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.

Screenshot of Git command line interface showing list of rules

We appreciate your feedback in GitHub's public feedback discussions

See more

Manage branch protection rules with a new permission

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.

Image of Custom roles that shows the new Edit Repository Rules permission

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.

See more

False-alert flags will appear in audit logs due to a bug in branch protections

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.

an audit log entry with the flash message displayed above it

See more

New Branch Protections: Last Pusher and Locked Branch

Today we're releasing two new branch protections.

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.

Screenshot of Last Push protection enabled.

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.

Screenshot of Lock branch with fork sync enabled

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.

See more

Improved UI for syncing a fork

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.

Image of sync fork button

Read more about branches.

Read more about working with forks.

See more

Bypass branch protections with a new permission

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.

Image of Custom roles Inherited from Maintain role that adds the new Bypass branch protections permission

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.

Image of checkbox selecting Do not allow bypassing the above settings

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.

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

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

See more

You can now fork a repo and copy only the default branch

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.

New fork page with ability to copy only the default branch

If you want to copy additional branches from the parent repository, you can do so from the Branches page.

Read more about copying additional branches.

Read more about branches.

Read more about working with forks.

See more

Consistently allow GitHub Apps as exceptions to branch protection rules

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

Compare differences between branches

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.

image

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

Required Deployments

You can now require a successful deployment of a branch before its pull request can be merged. This is made possible by a new branch protection setting titled Require deployments to succeed before merging. To enable the setting, create a new branch protection rule for the target branch. Then, select the environments where deployments must succeed before a pull request can be merged, shown here:

image

This will allow you to ensure code is, for example, exercised in a staging or test environment before it's merged to your main branch.

Learn more about protected branches
Learn more about branch protection rules

See more

Delete a branch with an open pull request

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