Request Changes

What Is Request Changes?

Request Changes is a formal code review action available on platforms like GitHub that allows a reviewer to block a pull request from being merged until specific issues are resolved. When a reviewer submits a review with the “Request Changes” status, the pull request enters a blocked state: if branch protection rules require approving reviews, the PR cannot merge until that reviewer either approves the changes or their review is dismissed by an administrator.

Unlike a simple comment, which is purely advisory, Request Changes carries enforcement weight. It is the reviewer’s strongest signal short of closing the PR outright. The action communicates: “I have identified issues that must be fixed before this code is safe to merge.” It creates a formal handshake — the author addresses the feedback, pushes updated code, and re-requests review, at which point the reviewer re-evaluates and either approves or requests further changes.

Request Changes occupies the middle ground in GitHub’s three review statuses. A “Comment” review provides feedback without taking a formal stance on mergeability. An “Approve” review signals readiness to merge. Request Changes explicitly signals that the code is not ready. Teams that use branch protection effectively rely on this three-tier system to maintain clear communication about the state of every pull request.

How It Works

On GitHub, the Request Changes workflow follows a structured pattern. When a reviewer opens the pull request’s “Files changed” tab, they can leave inline comments on specific lines of the diff and then submit the review with one of three statuses:

Review statuses on GitHub:
  - Comment:          Advisory only, does not block merge
  - Approve:          Signals readiness, counts toward required reviews
  - Request Changes:  Blocks merge until reviewer re-reviews

When branch protection is configured to require reviews, a Request Changes review prevents merging even if other reviewers have approved:

Reviewer A:  Approve         -> +1 approval
Reviewer B:  Request Changes -> merge blocked
Reviewer C:  Approve         -> +1 approval (total: 2)

Status: Cannot merge (Reviewer B has requested changes)

The block remains in place until Reviewer B submits a new review with either “Approve” or “Comment” status, or until a repository administrator dismisses the review. This prevents teams from circumventing a reviewer’s concerns by collecting enough approvals from others.

After the author addresses the feedback, the typical workflow is:

1. The author pushes new commits addressing the reviewer’s concerns.
2. The author replies to each comment, explaining how they resolved it or why they took a different approach.
3. The author clicks “Re-request review” to notify the reviewer that the PR is ready for another look.
4. The reviewer examines the new changes, verifies the issues are resolved, and submits an “Approve” review.

On GitLab, the equivalent mechanism works through the merge request approval system. A reviewer can block a merge request by withholding their required approval. Azure DevOps provides a “Rejected” vote that functions similarly to GitHub’s Request Changes.

Why It Matters

Request Changes is the enforcement mechanism that gives code review its teeth. Without a formal way to block merges, code review becomes purely advisory — and advisory processes are routinely skipped under deadline pressure. The impact of this mechanism is significant:

• It prevents premature merges. When a reviewer identifies a security vulnerability, a race condition, or a logic error, Request Changes ensures the PR cannot be merged while the issue remains unresolved. This is especially important on large teams where multiple reviewers may be active and the author might try to merge after receiving approvals from less critical reviewers.
• It creates accountability. The reviewer’s name is attached to the block. This means they must follow through: re-reviewing promptly when the author pushes fixes, and not leaving the PR in limbo. The formal nature of the action raises the stakes for both parties.
• It provides a clear audit trail. For compliance purposes, the history of Request Changes reviews and subsequent approvals documents exactly what issues were raised, how they were resolved, and who signed off on the resolution.
• It signals severity unambiguously. In the absence of Request Changes, reviewers must rely on comment tone and wording to communicate urgency. With a formal blocking action, there is no ambiguity about whether an issue is a suggestion or a requirement.

Best Practices

1. Only use Request Changes for issues that genuinely warrant blocking. Style preferences, naming opinions, and minor refactoring suggestions should be communicated as comments or nitpicks. Reserve Request Changes for bugs, security issues, missing error handling, broken tests, or violations of architectural principles. Overusing Request Changes creates a culture of fear around code review.
2. Pair every Request Changes review with specific, actionable feedback. Each blocking comment should identify the problem, explain the risk, and suggest a solution. A Request Changes review with no inline comments or vague feedback like “needs work” is unhelpful and adversarial.
3. Re-review within hours, not days. When you request changes, you have created a dependency — the author cannot make progress until you follow up. Treat re-reviews with the same urgency as the initial review. A good target is re-reviewing within four hours of the author’s update notification.
4. Resolve your own comments. On GitHub, when you leave comments as part of a Request Changes review, resolve them yourself once you verify the fix rather than leaving them open and confusing the next reviewer.
5. Use the re-request review feature. Authors should explicitly re-request review after addressing feedback rather than leaving a comment like “done” and hoping the reviewer notices. This triggers a notification and moves the PR back into the reviewer’s queue.

Common Mistakes

1. Using Request Changes for nitpicks. If the only issues are cosmetic — variable naming, comment wording, import order — use a “Comment” review or approve with inline suggestions. Blocking a PR over formatting issues wastes the author’s time and erodes trust in the review process.
2. Requesting changes and then disappearing. A Request Changes review that is not followed up promptly creates a bottleneck. The PR sits blocked, the author’s context fades, merge conflicts accumulate, and the team’s velocity drops. If you will be unavailable for an extended period, either avoid Request Changes and leave comments instead, or ask another reviewer to take over.
3. Not distinguishing between “must fix” and “consider fixing” in the review body. A Request Changes review can contain both blocking issues and optional suggestions. If the review does not clearly differentiate between the two, the author may spend time on low-priority changes while missing the critical issues — or may feel overwhelmed by the volume of feedback when only a subset truly requires action.