Announcing important changes to what it means for a pull request to be 'approved'.
If you use pull requests with protected branches, there are some important security improvements rolling out now that may impact your workflow:
- Merge commits created locally and pushed to a protected branch will be rejected if the contents differ from the system-created merge.
- The branch protection for dismissing stale reviews now dismisses approvals whenever a merge base changes after a review.
- A pull request approval now only counts towards the pull request it was submitted against.
Note: You may see some older approvals dismissed as we rollout these changes.
Read on to learn more about the specific changes:
User-created merges must have the same contents as the system-created merge.
Previously, it was possible for users to make unreviewed changes to a protected branch, by creating the merge commit locally and pushing it to the server. The merge would be accepted, so long as the parents commits were set correctly.
Going forward, manually creating the merge commit for a pull request and pushing it directly to a protected branch will only succeed if the contents of the merge exactly match the system-generated merge for the pull request. This new check will be enforced on branches where the branch protections mentioned earlier are enabled.
Pull request approvals will become stale if the merge base changes
A pull request approval will be marked as stale when the merge base changes after a review is submitted.
The merge base of a pull request is the closest common ancestor of both the target and source branches for that pull request. It is often (but not always) the commit where a user has branched off the mainline development and started working on a topic branch:
When "dismiss stale approvals" is enabled, the review will be dismissed and needs a re-approval. If branch protection rules specify that every push needs to be reviewed by a second contributor, a change in the merge base will require fresh approvals.
Merge bases changing under a pull request will preserve approvals in most situations where no new changes are introduced.
Pull requests no longer combine approvals.
Previously it was possible for a branch protected by "required pull request review" to be merged without an approved PR. This was possible because approvals were gathered across multiple independent pull requests if the feature branches pointed to the same commit as well as targeting the same branch.
We appreciate your feedback in GitHub's public feedback discussions.