github
Pull request revisions and improved workflows
Summary Pull request revisions provide "markers" during the lifetime of a pull request that allows reviewers to quickly focus on the code that changed and needs their feedback and approval. Reviewers are only notified about updates the author has deliberately marked as reviewable.
Revisions are persisted across force pushes, making it possible to view and compare changes at any point in the history of a pull request.
Intended Outcome Help pull request authors signal to their teammates when their code is ready to be reviewed, and also help reviewers to more easily identify which code has changed since their previous review. Also allows users to compare and view earlier changes which are currently not accessible.
How will it work?
- Pull requests can be in either Draft (not ready for review), Ready for Review, or a new state: In Progress. This new state signals new changes have been pushed, but are not quite ready for review.
- A push (update) to a pull request in Ready for Review will change the pull request's state to In Progress automatically, and it's the author's responsibility to mark the pull request ready for review. This lets an author push multiple updates or wait for updates to pass CI checks before notifying reviewers.
- A revision is created for each version of the pull request marked as ready for review.
- Reviewers are only notified when there is a new revision, meaning fewer notifications that are more actionable.
- The pull request Files changed tab filters to changes since my last review by default, helping the reviewer focus on what's new since they last reviewed the pull request.
- Reviewers can compare changes between revisions similarly to the way they can compare changes between commits today.
