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.

Pull request merge queue (public beta)

Today we are announcing the public beta of pull request merge queue for repos on GitHub Enterprise Cloud and open source organizations! 🎉

Merge queue helps increase velocity in software delivery by automating pull request merges into your busiest branches.

Pull request merge queue

Before merge queue, developers were often required to update their pull request branches prior to merging to ensure their changes wouldn't break the main branch when merged. Each update resulted in a fresh round of continuous integration (CI) checks that would have to finish before the developer could attempt to merge. If another pull request got merged, every developer would have to go through the process again.

Merge queue automates this process by ensuring each pull request queued for merging is built with the pull requests ahead of it in the queue.

Queueing a pull request to merge

If your pull request targets a branch that uses merge queue, instead of merging your pull request directly when it meets the requirements to merge, you will add it to the queue by clicking Merge when ready from the pull request page or from GitHub Mobile.

Queue to merge

The queue then creates a temporary branch that contains the latest changes from the base branch, the changes from other pull requests already in the queue, and the changes from your pull request. CI then starts, with the expectation that all required status checks must pass before the branch (and the pull requests it represents) are merged.

If a queued pull request has merge conflicts or fails any required status check, it is automatically removed from the queue when it reaches the front, and a notification is sent. Once the problem is resolved, it can be added back to the queue.

Learn more about merging a pull request with merge queue from the pull request page. You can also queue your pull request on the go using the beta version of GitHub Mobile from iOS TestFlight or Google Play (Beta)!

Viewing the queue

Always know where you are in the queue.

The queue details page, which can be accessed from the Branches page or pull request page, shows the pull requests in the queue and status for each, including the required status checks and estimated time to merge. It also shows how many pull requests have been merged and the trend over the last 30 days.

Merge queue details page

Depending on your permissions, you can also remove a pull request from the queue or clear the queue from this page.

Getting started

Merge queue can help improve overall velocity and avoid manual branch updates that impact developer productivity. Learn more about how to enable merge queue on your busiest branches.

We want to hear from you on how we can improve merge queue! Join the conversation in the merge queue public beta discussion.

See more

Sunset Notice – Team Discussions

Today we are announcing the deprecation of Team Discussions, which will have individual sunset timelines for GitHub.com, API, and GHES users. Please see below for full details.

Last year, we introduced Organization Discussions, a way for teams to scope their discussions to the organization-level rather than the repository-level. Today, Organization Discussions has grown to include a number of features – including Categories, Category forms, Threaded comments, Q&A features (marking a comment as an answer), Polls, and Labels.

As we continue to invest and enhance Organization Discussions, we will be sunsetting Team Discussions. To migrate your existing Team Discussions to Organization Discussions, maintainers can click on the banner at the top of their Team Discussions page:

Screenshot 2023-02-07 at 3 32 28 PM

Following deprecation, access to any unmigrated Team Discussions will be available as raw text, but there won't be any ability to add, modify, or delete Team Discussions.

The deprecation will follow these timelines:

GitHub.com Timeline:

  • Feb 8, 2023: A banner to migrate will be visible to maintainers at the top of their Team Discussions page, with the migration tooling included.
  • May 8, 2023: Team Discussions will be deprecated.
  • After May 8, 2023: Access to unmigrated Team Discussions will be available as raw text, but the UI won’t be available to add, modify, or delete Team Discussions.

GHES Timeline:

  • August 8, 2023: Team Discussions will be marked for deprecation in version 3.10. A banner to migrate will be visible to maintainers at the top of their Team Discussions page, with the migration tooling included.
  • February 27, 2024: Team Discussions will be removed in version 3.12.
  • After February 27, 2024: Access to unmigrated Team Discussions will be available as raw text, but the UI won’t be available to add, modify, or delete Team Discussions.

API Timeline:

  • The Team Discussions API will be deprecated in the next calendar version (no sooner than April 30th, 2023)

For questions or feedback, please visit our community.

See more
View all changes