Pull Requests and Code Review

What you will learn

• Understand the core purpose of Pull Requests and Code Review
• Master the basic usage and common options of Pull Requests and Code Review
• Understand pull requests, reviews, protected branches, and merge decisions as collaboration mechanics rather than just UI actions.
• Understand key concepts: Why a PR is more than a merge request
• Know when to use this feature and when to avoid it

Start with a problem

You're already using GitHub or GitLab to host code, but beyond push and pull, you're not fully familiar with the collaboration features these platforms offer — PR workflows, code review, and permission management.

Why a PR is more than a merge request

PR Creation

Feature branch readyPR description completeLinked Issue

→PR Review

Merge or Revise

CI auto-checksPeer code reviewRequest changes or approveMerge to target branch

Good PR descriptions include: change purpose, implementation approach, test coverage, screenshots (if applicable), linked Issues.

Many teams use pull requests every day but still underuse them.
A good PR is not only a gate before merge. It is also where a team:

• explains why the change exists
• inspects what changed
• reviews tradeoffs
• runs platform checks
• makes a merge decision together

That is why understanding review quality matters just as much as understanding the GitHub interface.

What review is really evaluating

A mature review is rarely just about syntax or style. It usually asks:

• is the goal clear?
• is the scope reasonable?
• does the change introduce obvious risk?
• is the structure maintainable?
• have the right checks already run?

In other words, review is not just "spot bugs." It is a collaborative engineering judgment.

◉A PR is the container; review is the team judgment inside it

Once you see a PR as a shared decision surface instead of a merge form, many best practices start to make more sense. Description quality, commit hygiene, and testing notes all become part of review quality.

GitHub's review outcomes matter

GitHub distinguishes among:

• Comment
• Approve
• Request changes

Those are not cosmetic buttons. They help teams distinguish between light feedback, approval, and blocking concerns.

A healthier PR rhythm

This sequence is usually more stable:

1. clean up local history first
2. open the PR with strong context
3. let checks run early
4. keep pushing review fixes as needed
5. resolve threads and confirm risk areas
6. merge with the agreed strategy

Teams struggle when they reverse that order and use the PR as a place to figure out the change after the fact.

Why protected branches matter

Protected branches help turn team expectations into platform rules, such as:

• required reviews
• required status checks
• blocked direct pushes
• branch freshness before merge

That is useful because it lets GitHub enforce the minimum quality line consistently.

!Platform rules enforce a floor, not engineering judgment

Passing checks and satisfying branch rules does not automatically make a change well scoped or well reasoned. Good pull requests still depend on team habits.

What makes a PR easier to review

The best way to improve review is usually not "ask for review sooner." It is to reduce reviewer cost:

• keep the goal narrow
• write the background clearly
• avoid messy commit stacks
• explain how the change was verified
• call out known risks and tradeoffs

That is why topics like pull-request prep and small-batch review stay valuable across teams.

Common anti-patterns

Giant PRs

When the review surface is too large, reviews become shallow.

Unresolved discussion flow

If the author keeps pushing changes but never resolves or answers review threads clearly, review cost accumulates fast.

Using squash to hide process problems

Squash merge can be useful, but it should not become a way to hide chaotic change preparation every time.

Good follow-up reads

• prepare commits before a pull request
• pull-request prep
• small-batch review
• merge strategy and platform settings

Try it yourself

1. Practice the pull-requests-and-reviews command in a test repository and observe state changes before and after
2. Experiment with different options and compare the output differences
3. Simulate a real scenario where you would need to use this, and walk through the full process