Protected Branches Improvements

Over 100,000 people push to protected branches nearly 300,000 times every week. We’ve been listening to how we can make protected branches even better and we’re happy to introduce two…

|
| 1 minutes

Over 100,000 people push to protected branches nearly 300,000 times every week. We’ve been listening to how we can make protected branches even better and we’re happy to introduce two workflow improvements.

Merging out-of-date pull requests

Required status checks currently provide a strong guarantee of compatibility between a pull request’s base and head branches. Not only must the status checks be passing, the head branch must also be up to date with the protected base branch in order to be merged. This catches hard-to-spot incompatible changes that don’t cause merge conflicts but result in broken code nonetheless.

The extra status check runs required by this policy can be a burden for teams where many changes are being made to a protected branch. To make this easier for those teams, we’ve added a setting which will still enforce required status checks but will no longer require a pull request to be up to date before merging.

Toggle whether a branch has to be up to date with a protected branch

User and team restrictions

Sometimes merges to a protected branch are best left to a release manager or a team of people responsible for the stability of that particular branch. Organizations can now specify which members and teams are able to push to a protected branch. Note that organization and repository administrators are always able to push.

Choose which users and teams can push to a protected branch

Protected branches help you keep your codebase safe from force pushes and buggy code. These changes give you better control over whom can push to your protected branches and make the experience for very active repositories much smoother. Check out the documentation for more information or get in touch with any questions or feedback.

Written by

Related posts