iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Request changes when a specific, material problem means the code should not merge yet: for example, a correctness defect, security or reliability risk, substantial maintainability cost, undue complexity, or failure to meet an agreed requirement. Explain the impact and what would resolve the concern. Keep preferences and minor polish in ordinary, non-blocking comments.
Choose the review outcome by the issue’s impact
A review decision should make clear whether the author needs to address an issue before merge. Separate blocking concerns from questions, observations, and optional improvements so feedback is useful without turning personal preference into a gate.
| Outcome | Use it when | What it tells the author |
|---|---|---|
| Request changes | A concrete, material issue makes merging unsafe or inconsistent with an agreed project requirement. | Address the issue, or provide the evidence needed to establish that it is safe, before merge. |
| Comment | You have a question, observation, or useful suggestion that is not a merge condition. | Consider or answer the feedback; it is not necessarily a prerequisite for merge. |
| Approve | The change meets the relevant standards and improves the codebase enough to merge, even if minor imperfections remain. | The review supports merging, subject to the repository’s configured rules. |
Google’s published code-review standard says reviewers should generally favor approving a change once it definitely improves overall code health, even if it is not perfect. It also cautions against checking in changes that definitely worsen code health except in an emergency. That is Google’s guidance; apply your own project’s requirements and risk tolerance. Google Engineering Practices: The Standard of Code Review.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What justifies a blocking request?
Base the decision on the change’s behavior and context, not on whether you would have written it differently. Google’s reviewer guidance highlights functionality, complexity and over-engineering, and adherence to established style guidance. Google Engineering Practices: What to Look For in a Code Review.
#1 Best Overall
- Correctness or functionality: The change produces the wrong result, breaks an expected behavior, or mishandles an important case.
- Security or reliability: The implementation creates a meaningful exposure or failure risk under identifiable conditions.
- Maintainability or complexity: The change materially degrades the codebase—for example, by adding unnecessary complexity that will make future changes harder.
- Project requirement: The change does not meet a documented or agreed requirement, including an established style rule when that rule applies.
A style preference that the project does not require is not, by itself, a blocking standard. Offer it as a suggestion instead.
Check the threshold before requesting changes
- Identify the concrete concern. Point to a behavior, risk, requirement, or material maintenance cost—not simply a different approach you prefer.
- Describe the consequence. Explain what could go wrong and for whom: users, operators, security, correctness, or future maintainers.
- Set a reasonable resolution bar. State what change or evidence would make the issue safe to merge. If the right fix is unclear, ask a focused question and explain why the answer affects approval.
- Keep optional feedback separate. Label polish, teaching notes, and alternative approaches as non-blocking so the author can distinguish them from merge conditions.
Write a comment the author can act on
A useful blocking comment identifies the relevant code or behavior, names the conditions that trigger the problem, explains the impact, and states what would resolve it. Avoid vague instructions such as “fix this,” and do not turn a single concern into a demand to polish every line.
For example, rather than saying “This is unsafe,” describe the input or timing condition that causes the unsafe behavior, the resulting risk, and the correction or test that would demonstrate the issue is addressed. If multiple comments point to the same underlying problem, explain the shared decision and connect the comments so the author can see what is required for approval.
How GitHub’s review decision affects merging
GitHub provides three review outcomes: Comment, Approve, and Request changes. Its documentation describes Request changes as feedback the author should address before the pull request merges. GitHub Docs: Giving feedback on a pull request.
A request does not universally create a technical lock. Whether it blocks a merge depends on repository settings and permissions: GitHub says a request-changes review or a dismissed approval can block merging when required approvals or code-owner review are configured. Check the repository’s rules rather than assuming every request has the same effect. GitHub Docs: Dismissing a pull request review.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Be timely without approving prematurely
Google Engineering Practices recommends responding to a review request within one business day. That is Google’s recommendation, not a universal service-level agreement. The same guidance emphasizes spending enough time to be confident that an approval means the change meets standards. If a complete review will take longer, tell the author when to expect it or provide a brief first pass; do not substitute a fast, unsupported approval for a meaningful review. Google Engineering Practices: The Reviewer’s Response Time.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
