What Exactly Is a Pull Request? A Complete Guide to the Code Review Process

What a Pull Request (PR) Is

Pull Request (PR) or Merge Request is a request for the team to review and merge code into the main branch, not merely a code push.

PR requests team review and merge, not just a code submission.

Information a PR Shows

Changed files

Diff per file

Commit history

Automated test results

Reviewer approvals

Merge conflicts

Risks of Direct Pushes to main

Allowing anyone to push directly to main can lead to half‑finished features, undiscovered bugs, overwritten work, untested releases, misunderstood requirements, and security issues.

Typical PR Requirements in Mature Teams

All changes go through a PR

At least one reviewer approves

CI tests pass

No merge conflicts

Code follows style guidelines

Critical modules need owner approval

Standard PR Workflow (Example: Adding SMS Login)

Create a feature branch, develop, push, and open a PR.

git checkout main
git pull origin main
git checkout -b feature/login

After development:

git add .
git commit -m "feat(login): add sms login"
git push origin feature/login

Open a PR from feature/login to main on GitHub/GitLab/Gitee. feature/login → main Review pipeline:

Submit code → Open PR → Automated tests → Code Review → Feedback → Re‑submit → Approval → Merge to main

What Reviewers Examine

Correct implementation of requirements

Reliability of logic (boundary conditions, exceptions, null handling, concurrency, permissions)

Maintainability (clear naming, reasonable structure, no unnecessary complexity)

Impact on other modules

Security risks (token leakage, permission bypass, sensitive data exposure)

Sufficiency of tests (coverage of critical paths, added tests)

Writing a High‑Quality PR

A PR description should include the following sections.

Background

Add phone‑code login feature.

Changes

New SMS login API

Form validation on login page

Token refresh logic

Additional login‑failure tests

Verification

Run pnpm test Manual test of success/failure scenarios

Risks

Token refresh may affect existing sessions

Verification‑code expiry handling

Why Small PRs Work Better

Large PRs often mix new features, refactoring, style changes, dependency upgrades, bug fixes, and formatting, making review painful.

Splitting into focused PRs (e.g., PR 1 for API, PR 2 for UI, PR 3 for tests, PR 4 for refactoring) yields:

Easier to understand

Higher chance of spotting issues

Simpler to roll back

Faster merges

Lower conflict probability

Handling Review Feedback

Typical response patterns include:

“Fixed, added null‑check.”

“Keeping current implementation for backward compatibility.”

“Created a separate PR for the refactor.”

Post‑Merge Checklist

Delete the feature branch locally: git branch -d feature/login Confirm CI still passes on main.

If released, monitor logs and metrics.

Create follow‑up tasks for any remaining technical debt.

PR Command Cheat Sheet

git checkout main          # switch to main
git pull origin main       # update main
git checkout -b feature/login  # create feature branch

git add .                  # stage changes
git commit -m "feat(login): add sms login"  # commit
git push origin feature/login  # push branch

git status                # view status
git log --oneline         # view history
git diff main             # diff against main

Conclusion

Pull Request is a safety gate that ensures code undergoes discussion, testing, review, and confirmation before entering the main branch.

Key takeaways:

PR requests team review and merge, not just code submission.

High‑quality PRs describe background, changes, verification, and risks.

Small, focused PRs are safer and easier to review than large, mixed ones.