Most developers know how to open a pull request. Fewer know exactly what happens during the approval step, and why getting it wrong blocks merges in ways that aren’t always obvious.
Knowing how to approve a pull request in GitHub means understanding more than clicking a button. It involves review states, branch protection rules, required reviewers, and permission levels.
This guide covers:
- What a pull request approval actually does
- Permission and branch protection requirements
- Step-by-step approval via the GitHub UI and GitHub CLI
- Common errors and how to fix them
By the end, you will know how the full pull request review process works and what to check when a merge stays blocked after approval.
What Is a Pull Request Approval in GitHub
A pull request approval is a formal review state in GitHub that signals a reviewer has accepted proposed code changes. It is 1 of 3 possible review outcomes: Approve, Request changes, and Comment. Only an approval moves a PR toward merge eligibility.
GitHub merged 518.7 million pull requests in 2025, a 29% year-over-year increase (GitHub Octoverse 2025). That volume makes understanding the approval process genuinely important, not just for solo developers but for any team managing a shared codebase.
How approval differs from commenting
Submitting a comment leaves the pull request review state unchanged. The PR stays in “pending review” status. An approval explicitly changes the review state to “Approved” and counts toward merge requirements set in branch protection rules.
Key distinction: Comments are informational. Approvals are gating. On a protected branch requiring 2 reviews, 10 comments from 10 people still blocks the merge. 2 approvals from reviewers with write access unlock it.
Where approval fits in the pull request lifecycle
The pull request lifecycle runs: open PR → assign reviewers → review changes → approve or request changes → pass status checks → merge. Approval sits at step 4. It does not trigger a merge on its own.
All 3 conditions below must be true before a merge is possible:
- Required number of approvals received
- Required status checks (CI, tests) passed
- No “Request changes” review blocking merge
The code review process determines the overall pull request quality gate. Approval is the final signal within that gate.
The 3 review states explained
| Review State | Effect on PR | Counts Toward Merge |
|---|---|---|
| Approve | Marks the pull request as accepted and increases the approval count | Yes |
| Request changes | Blocks merging until the reviewer approves after requested updates | No |
| Comment | Adds feedback without affecting approval or merge status | No |
Pull request authors cannot approve their own PRs. This is a hard platform restriction, not just a setting (GitHub Docs).
What Are the Requirements to Approve a Pull Request
Approving a pull request requires write access or higher to the repository. Read-only collaborators cannot submit approving reviews that count toward merge requirements. This applies to both personal repositories and GitHub organization repositories.
Teams that introduced peer review saw a 90% decrease in defects and a 14% increase in productivity, based on an AT&T internal study cited in Codacy research. Permission controls exist precisely to make sure those reviews come from people accountable for the codebase.
Repository permission levels and approval rights
Write access: Can approve PRs. Approvals count toward required review thresholds.
Read access: Can comment on PRs. Cannot submit approvals that count toward merge requirements.
Admin access: Can approve PRs and bypass branch protection rules (if the rule allows it). Can also dismiss other reviewers’ approvals.
In organization repositories, the team role matters. A team member with read access to a repo cannot count as a required reviewer, even if they are listed in the CODEOWNERS file and their team is assigned.
Branch protection rule requirements
Branch protection rules define how many approvals are needed and from whom. These settings live at Settings > Branches > Branch protection rules in the repository.
- Required number of approvals: Set to any value from 1 to N. Default is 0 (no approvals required).
- Require review from Code Owners: If enabled, at least 1 CODEOWNERS-designated reviewer must approve files they own.
- Dismiss stale reviews: If enabled, any new commit to the PR branch invalidates existing approvals. The PR needs re-approval.
- Restrict who can dismiss reviews: Limits which users or teams can dismiss an existing approval.
Self-approval restriction
GitHub enforces a hard platform rule: PR authors cannot approve their own pull requests. This applies everywhere, regardless of branch protection settings. No configuration overrides it.
This is worth knowing if you are a solo contributor or the only admin on a repo. You will need at least 1 other collaborator with write access to satisfy any approval requirement.
How to Approve a Pull Request in GitHub
Approving a pull request takes 4 steps in the GitHub UI: navigate to the PR, open the “Files changed” tab, open the review panel, select “Approve,” and submit. The entire process happens in the browser without any command-line tools.
Codacy’s survey of 680 developers found that 1 in 5 identified code review as the single most important activity for improving code quality. Getting the submission flow right matters for both review accuracy and team velocity.
Step-by-step: Approving via GitHub.com
- Open the pull request in the repository.
- Click the Files changed tab to review the diff.
- Click the green Review changes button (top right of the Files changed view).
- In the review summary panel, select the Approve radio button.
- Optionally add a review comment in the text field.
- Click Submit review.
The PR status updates immediately. If this approval satisfies the required count, the merge button activates (assuming status checks also pass).
Approving via GitHub CLI
Basic approval command:
gh pr review [PR-NUMBER] --approve
Add a comment alongside the approval:
gh pr review [PR-NUMBER] --approve --body "Looks good, tested locally on main."
To find PRs waiting for your review:
gh pr list --review-requested @me
The CLI requires authentication with a token that has repo scope. Personal access tokens (classic) or fine-grained tokens with pull request read/write permissions both work. The GitHub CLI installation must be completed before these commands run.
Approving via GitHub Mobile
GitHub Mobile supports full PR review submission, including approval. Open the PR in the app, tap “Files changed,” review the diff, tap the review icon, select “Approve,” and submit. The mobile approval counts toward branch protection requirements the same as a desktop approval.
Worth noting: leaving inline comments on specific lines is available in mobile but the UI is smaller. For complex reviews with many file changes, desktop is more practical.
How to Approve a Pull Request with Required Reviewers
When branch protection rules require review from specific people or teams, approval from those exact reviewers is the only approval that unblocks the merge. A general approval from someone else does not count toward that specific requirement.
GitHub now hosts over 180 million developers across more than 630 million repositories (Octoverse 2025). Large organizations routinely use required reviewers and CODEOWNERS rules to manage review accountability at that scale.
How assigned reviewers work
Assigned reviewer: Suggested reviewer added manually or via automation. Their review is requested but not always required to unblock merge.
Required reviewer (via CODEOWNERS): When “Require review from Code Owners” is enabled and the PR touches a file with a designated owner, that owner must approve. No other reviewer can substitute.
Required reviewer (via branch protection): Admins can set required reviewers explicitly in branch protection rules. All of them must approve.
One thing that trips up teams: a CODEOWNERS approval is satisfied by any code owner listed for the affected file, not necessarily all of them. If 3 people own a file, 1 approval from any of those 3 is enough (GitHub Docs).
CODEOWNERS file: what it does
The CODEOWNERS file maps file paths to GitHub users or teams. It lives at .github/CODEOWNERS, docs/CODEOWNERS, or the root of the repository.
Example CODEOWNERS syntax:
# All .js files require review from the frontend team
*.js @org-name/frontend-team
# The /api directory requires review from @apidev
/api/ @apidev
When Require review from Code Owners is active in branch protection, any PR touching these paths automatically requests a review from the listed owners and blocks merge until they approve.
Re-requesting a review after changes
After pushing new commits to a PR, previously given approvals may be dismissed (if “Dismiss stale reviews” is on). The reviewer receives a new notification. The PR author can also manually re-request a review using the refresh icon next to the reviewer’s name in the PR sidebar.
This is one of the more common friction points in team workflows. Reviewers sometimes miss the re-request notification and the PR sits blocked without anyone knowing why. Good practice: post a comment tagging the reviewer when pushing significant changes.
How to Approve a Pull Request as an Organization Member
Approving PRs in a GitHub organization repository follows the same steps as personal repos, but organization-level roles, team assignments, and audit logging add layers that matter for compliance and access control.
Organization roles and their effect on approval
| Role | Can Approve PRs | Can Bypass Branch Protection |
|---|---|---|
| Organization Owner | Yes (if they have write access to the repository) | Yes, if bypass rules are configured |
| Organization Member with Write access | Yes | No, by default |
| Organization Member with Read access | No, approvals do not count toward merge requirements | No |
| Outside Collaborator | Depends on the repository permission assigned | No, by default |
Team review requests in organizations
Organization teams can be assigned as reviewers on a PR, and they can be listed in CODEOWNERS. When a team is requested for review, GitHub notifies all team members. Any member with write access can then approve on behalf of the team request.
Teams can also be set as required reviewers in branch protection rules. In this case, at least 1 member from that team must approve before the merge is allowed.
Audit log for approvals
Every approval in an organization repository is logged in the organization’s audit log. The log captures: the reviewer’s username, the repository, the PR number, the timestamp, and the review action (approved, dismissed, changes requested).
Organization owners access this at Settings > Audit log. This matters for teams operating under software compliance requirements, where proof of human review before deployment is part of the audit trail.
What Happens After a Pull Request Is Approved
After the required approvals are received and all status checks pass, the merge button becomes active. The PR author or any collaborator with write access can then choose how to merge.
Programs developed with code reviews had 0.82 errors per 100 lines of code, compared to 4.5 errors per 100 lines in programs developed without reviews (Codacy research, citing a controlled study of 11 programs). The approval step is where that quality gate closes.
The 3 merge options
Merge commit: Creates a merge commit that preserves the full branch history. All commits from the feature branch appear in the target branch history individually.
Squash and merge: Combines all PR commits into a single commit on the target branch. Useful for keeping a clean, linear history when the feature branch has many work-in-progress commits.
Rebase and merge: Replays each PR commit onto the tip of the base branch without a merge commit. Keeps linear history while preserving individual commits.
Repository admins control which of these 3 options are available. Some teams disable squash and rebase to enforce a single merge strategy across the codebase. This connects directly to how teams manage their git flow strategy.
Auto-merge behavior
Auto-merge lets a PR merge automatically once all required conditions are satisfied. No manual click is needed. To enable it: open the PR, click “Enable auto-merge,” and select the merge method.
Auto-merge is useful in continuous deployment pipelines where PRs should merge to a staging branch as soon as CI passes and approvals are in. It eliminates the waiting period between “all checks pass” and “someone remembers to merge.”
What triggers stale review dismissal
If “Dismiss stale pull request approvals when new commits are pushed” is active, any new commit to the PR branch after approval dismisses all existing approvals. The PR needs to go through the review cycle again.
This catches a specific problem: a reviewer approves, the author pushes a new commit with unreviewed changes, and the PR merges. Stale review dismissal prevents that scenario. The tradeoff is more review cycles for PRs with iterative changes.
How to Dismiss or Change an Approval on a Pull Request
An approval can be changed or dismissed after submission. The original reviewer can re-submit their review with a different state. Admins can dismiss a review entirely if the reviewer is unavailable or the approval is no longer valid.
How a reviewer changes their own approval
To change from “Approve” to “Request changes”: go back to the PR, open the “Files changed” tab, click “Review changes,” and select a different review state. Submitting the new review replaces the previous one.
This comes up in practice. You approve a PR, the author mentions something in Slack, you take another look, and realize there is a problem. Re-submitting as “Request changes” immediately blocks the merge, which is the correct behavior. The source control management workflow depends on reviewers having this ability.
Admin-level review dismissal
Repository admins and users with write access can dismiss another reviewer’s blocking review if:
- The original reviewer is unavailable (left the org, off sick)
- The review is outdated and the admin confirms the issue is resolved
- The “Dismiss stale reviews” setting did not fire automatically
To dismiss: open the PR, find the review in the conversation timeline, click the three-dot menu next to the review, and select “Dismiss review.” A reason must be provided. This reason is stored in the audit log.
Dismissed reviews and audit trail
All dismissals are recorded. The audit log captures: who dismissed, whose review was dismissed, the PR, and the provided reason.
Teams using change management processes often require that review dismissals include a ticket reference or approval from a senior engineer. GitHub does not enforce this natively, but the reason field in the dismissal prompt is where that documentation goes.
How to Approve a Pull Request via GitHub CLI
The GitHub CLI lets you complete the entire pull request review submission without opening a browser. Approval, review status checks, and merge all run from one terminal session.
GitHub Octoverse 2025 reports developers merged 43.2 million pull requests per month on average in 2025, a 23% year-over-year increase. Teams running high PR volume increasingly rely on CLI workflows to keep review velocity up.
Core approval commands
Approve the current branch’s PR:
` gh pr review --approve `
Approve a specific PR by number:
gh pr review 42 --approve
Approve with a comment:
gh pr review 42 --approve --body "Tested locally, looks solid."
The GitHub CLI also supports –request-changes and –comment as review flags. You switch between them using the same command structure, just swapping the flag.
Finding PRs that need your review
GitHub Octoverse 2025 notes that PR comments dropped by 27% even as PRs increased. Tracking what actually needs your review is the first problem to solve.
List PRs assigned to you for review:
gh pr list --review-requested @me
Check current review status of a PR:
gh pr status
The git cheat sheet covers related commands for branch and commit management alongside CLI review operations.
Authentication requirements for CLI approval
CLI approvals require a valid authenticated session. Run gh auth login if not already authenticated.
Token scopes needed:
- Classic personal access tokens: repo scope
- Fine-grained tokens: “Pull requests” with read and write permissions
- OAuth via gh auth login: handled automatically
Organization repositories with SSO enabled require an additional step: the token must be authorized for the organization after creation. GitHub blocks the API call with a 403 error if this step is skipped.
How Pull Request Approvals Work with Branch Protection Rules
Branch protection rules are the enforcement layer that makes pull request approvals mandatory rather than optional. Without them, developers can merge directly to any branch without any review at all.
43.2 million pull requests merged per month on GitHub (Octoverse 2025). At that scale, protection rules are what separate coordinated team workflows from chaotic direct pushes to main.
Where to configure branch protection
Navigate to: Repository Settings > Branches > Branch protection rules > Add rule.
The branch name pattern field accepts exact names (main) or wildcards (release/). One rule can protect all matching branches at once.
Branch protection rules are available on all GitHub plans for public repositories. Private repositories require GitHub Pro, Team, or Enterprise plans (GitHub Docs).
Key settings that affect approval behavior
| Setting | What It Does | Default |
|---|---|---|
| Require pull request before merging | Forces all changes to go through a pull request before merging | Off |
| Required approvals (1 to N) | Sets the minimum number of approvals needed before merge is allowed | 0 |
| Dismiss stale reviews | Automatically resets approvals when new commits are pushed to the pull request | Off |
| Require review from Code Owners | Requires approval from matching entries in the CODEOWNERS file | Off |
How status checks interact with approvals
Approvals and status checks are independent gates. Both must pass before the merge button activates.
GitHub Actions workflows generate status checks automatically when triggered by a pull request event. A PR with 3 approvals but a failing CI run stays blocked until the checks pass.
This is where continuous integration and the pull request review process connect directly. The CI run validates the code; the approval validates the intent and approach. Both are required.
Rulesets vs. classic branch protection rules
Classic branch protection rules: One rule per branch. Simpler to set up. Cannot be layered.
Rulesets (newer): Multiple rulesets can apply to the same branch simultaneously. More restrictive rule wins when they conflict. Available for organization-wide enforcement across multiple repositories.
If a ruleset requires 3 approvals and a classic protection rule requires 2, GitHub enforces 3 approvals (GitHub Docs). The most restrictive setting always wins.
Teams setting up a git workflow with release branches should use rulesets instead of classic rules. Rulesets support wildcard patterns and apply consistently to current and future matching branches.
Bypassing branch protection as an admin
Repository admins can merge without meeting approval requirements by default. This bypass can be explicitly disabled by checking “Include administrators” in the protection rule settings.
Organization owners can also add specific users or teams to a bypass list in rulesets, allowing selective exceptions without disabling protection entirely for everyone else (GitHub Docs).
Common Errors When Approving a Pull Request
Most pull request approval errors fall into 3 categories: permission mismatches, stale review states, and status check conflicts. Knowing which error maps to which cause cuts debugging time significantly.
Merge still blocked after approval
The most common situation: 1 approval received, merge button still gray. 3 likely causes:
- The reviewer has read access only. Their approval shows a gray checkmark and does not count toward branch protection requirements (GitHub Discussions).
- Required status checks have not passed. Approval and CI are separate gates.
- A CODEOWNERS review is required and the specific owner has not yet approved, even if the general approval count is met.
Fix for the permission issue: go to repository Settings > Collaborators, find the reviewer, and change their role from Read to Write. Their next approval will count.
Approval reset after pushing new commits
Pushed a small fix after approval and the whole review got invalidated. This is “Dismiss stale pull request approvals” doing exactly what it is supposed to do.
GitHub records the diff state at the time of approval. Any new commit that changes the diff triggers dismissal. The PR needs re-approval from the original reviewers (GitHub Docs).
Workaround for minor commits: coordinate with your reviewer before pushing. If the change is trivial (typo, comment fix), some teams temporarily disable stale review dismissal, merge, then re-enable it. Not ideal, but faster than a full re-review cycle.
Cannot approve your own pull request
Direct statement. This is a hard platform rule with no configuration override. If you are the PR author, you cannot submit an approving review on your own PR (GitHub Docs).
Teams where one developer works alone need at least 1 other collaborator with write access to satisfy any approval requirement. If your repo has no other write-access collaborators, set the required approvals count to 0 in branch protection settings.
CODEOWNERS approval blocking merge
A CODEOWNERS approval error means the PR touches files with designated owners and none of them have approved yet, even if the general required approval count is satisfied.
Check which files triggered the CODEOWNERS requirement:
- Open the PR sidebar and look at the “Reviewers” section
- CODEOWNERS-required reviewers show a shield icon
- The specific team or user listed there must approve
If the CODEOWNERS reviewer is unavailable, a repository admin can dismiss the blocking review manually. See the CODEOWNERS file at .github/CODEOWNERS or the root directory to identify which paths map to which owners.
Merge base changed error after approval
GitHub shows “The merge-base changed after approval” when the base branch received new commits after the PR was approved. GitHub blocks the merge to prevent unsafe merges against an outdated base (GitHub Discussions).
Resolution:
- Click “Update branch” in the PR to pull in the latest base branch changes
- Request re-approval from reviewers
- Or close and reopen the PR to force GitHub to recalculate the merge base
If this happens repeatedly on a busy base branch, consider merging branches in GitHub more frequently to keep feature branches close to the base. The further a feature branch drifts, the more likely this error becomes.
FAQ on How To Approve A Pull Request In GitHub
How do you approve a pull request in GitHub?
Open the pull request, click the Files changed tab, then click “Review changes.” Select “Approve,” add an optional comment, and click “Submit review.” The approval is recorded immediately and counts toward any required review thresholds set in branch protection rules.
Who can approve a pull request in GitHub?
Any collaborator with write access or higher can submit an approving review that counts toward merge requirements. Read-only users can comment but their approvals show a gray checkmark and do not satisfy branch protection rules.
Can a pull request author approve their own PR?
No. GitHub enforces a hard platform restriction: pull request authors cannot approve their own pull requests. No branch protection setting overrides this. At least one other collaborator with write access must submit the approving review.
What is the difference between approving and commenting on a pull request?
A comment leaves the pull request review state unchanged. An approval explicitly changes the review state and increments the approval count toward merge requirements. Ten comments from ten people still block a merge if zero approvals have been submitted.
How do you approve a pull request using GitHub CLI?
Run gh pr review [PR-NUMBER] –approve from your terminal. Add –body “your comment” to include a review message. The CLI requires authentication with a token that has repo scope or a fine-grained token with pull request read and write permissions.
Why is a pull request still blocked after approval?
3 common causes: the reviewer has read-only access, required status checks have not passed, or a CODEOWNERS-designated reviewer has not yet approved. Approvals and CI checks are independent gates. Both must be satisfied before the merge button activates.
What happens to approvals when new commits are pushed?
If “Dismiss stale pull request approvals when new commits are pushed” is enabled in branch protection rules, all existing approvals are invalidated. The PR must go through the review cycle again before it can be merged.
How do you set up required approvals in GitHub?
Go to repository Settings > Branches > Branch protection rules, add a rule for your target branch, enable “Require pull request before merging,” and set the required number of approvals. Changes take effect on all new and open pull requests immediately.
What is a CODEOWNERS file and how does it affect pull request approvals?
The CODEOWNERS file maps file paths to specific GitHub users or teams. When “Require review from Code Owners” is active, any PR touching those paths requires approval from the designated owner. One approval from any listed owner for that file path is enough.
How do you dismiss or change an approval on a pull request?
The original reviewer can resubmit their review with a different state by returning to Files changed and selecting “Request changes.” Repository admins can dismiss any blocking review manually from the PR timeline, with a required reason recorded in the audit log.
Conclusion
This conclusion is for an article presenting how to approve a pull request in GitHub, covering everything from review states and write access permissions to branch protection rules and CODEOWNERS file configuration.
The pull request approval process is more than a formality. It is the gating mechanism that controls merge eligibility, enforces code review standards, and keeps protected branches stable.
Whether you submit reviews through the GitHub UI, GitHub Mobile, or the GitHub CLI with gh pr review –approve`, the underlying rules are the same.
Pay attention to stale review dismissal, required status checks, and reviewer permission levels. Those 3 factors explain most blocked merges.
Get the approval workflow right and the rest of your pull request review process follows naturally.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.
- How to Set Up Subscriptions on Google Play (Developer Guide) - July 12, 2026
- Why Work With a CMS Development Company for a Secure and Scalable Website? - July 12, 2026
- ADB Commands Cheat Sheet - July 11, 2026
