Skip to content

Require pull requests without requiring reviews

You can now require that all changes to a protected branch are made using a pull request, but without requiring reviews. This can be useful when you want to use pull requests for tracking purposes or to simplify your continuous integration (CI) configuration, but don't want to gate merging on review.

Previously, you could create a branch protection rule that required pull requests with approving reviews before commits could be merged into a branch. When pull requests were required, approving reviews were also required. This didn’t meet the needs of users who wanted to require pull requests for tracking purposes or CI validation, but who didn’t want their ability to merge to be gated by approving reviews.

Now, requiring pull requests and requiring approving reviews are separate options of protecting a branch. For example, you can now require pull requests without requiring reviews, or with requiring approving reviews. This flexibility lets you choose what is best for you and your branches.


For more information, visit Managing a branch protection rule.

Code scanning alerts now integrate with GitHub Issues task lists to make it easy to prioritize and track your alerts with all your development work.

You can use the task list feature in markdown to track a code scanning alert in an issue. When you add a code scanning alert to a task list in an issue, a "tracked in" pill will show on the corresponding alert page. The code scanning alerts page also shows which alerts are tracked in issues.

You can also create a new issue from a code scanning alert, which automatically adds the code scanning alert to a task list in the new issue.
Demo: tracking code scanning alerts in task lists

This feature has now shipped in beta for all users on

Learn more about tracking code scanning alerts in Issues using task lists.

See more

We made three improvements to the repository invite experience, so you can start contributing faster:

  1. You will now see notifications for private repository invites, just as you already do for public repositories.
  2. For pending invites to public repositories, you will now notice a banner on the repository overview, indicating that there is a pending invite.
  3. When you navigate to a private repository you have been invited to, you will now see a prompt to accept the invite instead of a 404 error page.
See more