“Changes requested” is one of the outcomes of a code review. On GitHub, a reviewer submitting a review chooses Comment, Approve or Request changes. Picking the last one puts a red status on the pull request and tells the author that something needs to change before it should merge.
When a repository uses branch protection with required reviews, a changes-requested review blocks merging until that reviewer approves a later version or the review is dismissed by someone with permission. GitLab works mostly through approval rules and discussion threads, and projects can require every thread to be resolved before a merge request can merge, which has a similar effect.
It is a normal part of review and not a judgment of the author. Most pull requests that land went through at least one round of it. The useful reviews explain why: “This query runs once per row, can we batch it?” gives the author something to act on.
As the author, respond to each comment. Fix it, or reply with your reasoning if you disagree. Push the changes, then use “Re-request review” so the reviewer gets notified, since a new push alone may not reach them. As a reviewer, separate blocking issues from preferences, and mark small preferences as nits so the author knows what actually stands between them and a merge.
If a review has sat at changes requested for a while and the reviewer is away, talk to them or to the team lead about dismissing it rather than routing around it.
The piece carries “CHANGES REQUESTED.” on the chest, in the same calm tone as the badge.
In the wild
Requesting changes on the retry logic. It retries on 4xx as well as 5xx. Everything else looks good.
