Approve / Get Approved: What It Is, Approval and Code Review in Git

What Is Pull Request Approval

Approval is a positive review of a pull request, meaning the reviewer has checked the code, found no critical issues, and considers the changes ready for merge. In the GitHub interface, this is the green “Approve” button on the PR page. After approval, the author (or any member with write access) can perform the merge.

The approval process is part of Branch Protection Rules. Repository owners configure mandatory requirements: minimum number of approvals (e.g., 1 or 2), who can approve (code owners, team members), and whether the PR must be re-approved after changes (Dismiss stale reviews). Without rule configuration, approval is optional, but in professional teams it is mandatory.

GitLab uses a similar mechanism called Approval Rules. In GitLab, you can configure how many approvals are required from different groups (e.g., 2 from backend developers and 1 from DevOps). After receiving all required approvals, the PR is automatically unlocked for merge provided the CI/CD pipeline is green.

Review Types: Approve, Request Changes, Comment

GitHub and GitLab have three types of reviews that a reviewer can leave on a pull request. Each type has a different status and consequences for the merge process. Approve is green, Request Changes is red, Comment is neutral gray. The choice depends on code quality and readiness of changes for acceptance.

Approve — the reviewer confirms: the code is written correctly, meets standards, contains no obvious errors, and can be merged. Approve does not mean the code is perfect — only that it is good enough for production. If there are minor comments (style, naming), they can be left as comments without blocking the PR.

Request Changes — the reviewer finds issues that must be fixed before merge: logic errors, vulnerabilities, architecture violations, missing tests. After Request Changes, the PR is blocked, and re-approval from the same reviewer is required to unblock (if the Dismiss stale reviews option is enabled on new commits).

• Approve — code is ready for merge, can be merged after CI passes.
• Request Changes — mandatory fixes required, PR is blocked until re-review.
• Comment — general remark or suggestion without blocking the PR.

Configuring Approval Rules in the Repository

Branch Protection Rules are GitHub’s mechanism for controlling merge quality. Configured in Settings → Branches for each protected branch (main, develop, release/*). Key parameters: number of required approvals, code owners (CODEOWNERS), mandatory CI/CD checks, and prohibition of pushes without a PR.

The Dismiss stale pull request approvals parameter automatically removes approvals if a new commit is added to the PR. This ensures that reviewers approve the exact version of code that will be merged. Without this setting, the author could add new code after approval and it would reach main without re-checking.

CODEOWNERS — a file in the repository root that assigns responsibility for different directories. If a PR affects files belonging to a code owner, their approval becomes mandatory. CODEOWNERS allows distributing areas of responsibility: iOS developers are responsible for Swift files, DevOps for Docker configs, testers for test scenarios.

# Example CODEOWNERS file in repo root

# iOS developers own Swift code
*.swift @team/ios-developers

# DevOps owns CI/CD configuration
.github/workflows/* @devops-team

# QA engineers review tests
**/tests/* @qa-engineers

# Default owners for everything else
* @tech-leads

Code Review Before Approval: What to Check

Code review before approval is a systematic code check, not a cursory glance at the diff. A quality code review includes checking architecture, logic, style, tests, and security. Without this check, approval becomes a formality rather than a quality control tool.

What is checked first: logic of changes — does the code solve the task, are there side effects, is edge case handling correct. Tests — do new tests cover all scenarios, do existing tests pass after changes. Security — are there SQL injections, XSS, sensitive data leaks.

What should not be subject to review: formatting style (that’s what linters and formatters are for), architectural decisions made in advance (they are discussed before writing code). If a review exceeds 400 lines or takes more than an hour, it’s a sign the task is too large and requires decomposition. Best review practices — portions of 200–400 lines within 24 hours of PR creation.

• Logic — correctness of the solution, error handling, edge cases.
• Tests — coverage of new scenarios, existing tests passing, no flaky tests.
• Security — no injections, output escaping, data access control.
• Performance — algorithm efficiency, excessive queries, memory leaks.
• Documentation — is documentation updated, are comments in complex sections clear.

Approval Workflow in a Team

A typical approval workflow in a team of 5–10 developers looks like this: a developer creates a PR, assigns reviewers (usually 1–2 people from the team or code owners), CI/CD runs automated checks. After receiving all required approvals and a green CI, the author performs the merge. Time from PR creation to merge averages 2 hours to 2 days depending on complexity.

GitHub Actions allow automating merge after approval. If branch rules are configured, GitHub automatically blocks merge until all conditions are met. Some teams use bors-ng or Mergify — bots that automatically merge PRs after receiving all approvals and passing CI. This speeds up the process and eliminates the human factor in merges.

A modern approach is trunk-based development with short-lived branches. In this workflow, approval must be obtained within a few hours, otherwise the task is considered stale and requires re-synchronization with main. Teams with a strong review culture aim for approval within no more than 4 working hours.

Approval Mistakes and How to Avoid Them

The most common mistake is formal approval without actual code review. When a PR is large or a deadline is close, a reviewer may click Approve without examining the changes. This devalues the entire code review process. Solution: set a limit on PR size (no more than 400 lines) and use code analysis tools (SonarQube, CodeClimate) for automated checking.

The second mistake is excessively strict approval. Expecting perfect code blocks development. Reviewers sometimes require fixing stylistic comments that don’t affect quality. Solution: clearly separate mandatory comments (blocking) from optional suggestions (comments). GitHub allows explicitly specifying whether a comment is blocking.

The third mistake is approval without checking CI/CD. Even if the code looks correct, it may not compile or may fail tests. Configured Branch Protection automatically blocks merge on a red CI, but some teams disable this protection for speed. Solution: always check CI status before approving and never approve a PR with a red pipeline.

• Formal approval — lack of actual code review. Solution: limit of 400 lines per PR.
• Excessive strictness — blocking due to stylistic comments. Solution: divide into blocking and optional.
• Ignoring CI — approval on a red pipeline. Solution: always check test status.
• Author assignment — approval by the PR author. Solution: configure Branch Protection against the author.