What is Pull Request?

From branch to merge

1. A developer does the work on a separate branch and pushes it to the shared repository.
2. They open a pull request against main with a title and description of what changed and why. Unfinished work can be opened as a draft to get early feedback.
3. The CI/CD pipeline runs automatically: build, linting, tests and often a preview deployment.
4. One or more teammates review the diff, leave line comments, and either approve or request changes.
5. The author pushes follow-up commits and the checks run again.
6. With approvals and green checks, the PR is merged, the branch is deleted and the change heads towards release.

How it is merged depends on how the team wants history to read. GitHub offers a merge commit that keeps every commit and adds a merge point, squash and merge that collapses the PR into a single commit, and rebase and merge that replays the commits onto the base branch for a linear history. Squashing keeps history readable when a PR is full of “fix typo” commits.

Writing a description reviewers can use

The reviewer was not in your head while you wrote the code. A short, complete description makes the review both faster and better:

## What changed
Tax ID is now required on the order form for business customers.

## Why
Accounting is correcting invoices by hand because business orders arrive without a tax ID.

## How to test
1. Log in with a business account and add a product to the cart
2. Submit with an empty tax ID: a validation error should appear

## Risk
Consumer checkout should be unaffected; tests added for both paths.

For UI changes, add before/after screenshots; for database changes, say whether the migration can be rolled back.

What code review is for

Review exists to catch defects before users do and to spread knowledge across the team, not to test the author. Reviewer time is best spent on:

• Correctness: does the code do what the description claims? Are edge cases, empty values and error paths handled?
• Security: is input validated, is authorization checked in the right place, has a secret slipped into the code?
• Tests: are there unit tests that pin the behaviour down, or only a happy-path check?
• Clarity and design: will the next person to touch this in six months understand what it does and why?

Formatting debates such as indentation or quote style should not involve humans at all; a formatter and linter settle them automatically. It also helps to label comments clearly as blocking or as optional nitpicks, so a PR does not sit idle for days over a suggestion.

Small PRs get real reviews

A twenty-line PR gets read carefully; a two-thousand-line PR usually gets skimmed and approved. There are ways to split large work: land a refactor before the behaviour change, ship the schema change before the code that uses it, or merge incomplete features behind a feature flag. Large PRs that stay open for weeks also invite merge conflicts, and every “we'll clean it up later” comment quietly turns into technical debt.

Enforcing the rules with branch protection

Team agreements work better when the platform enforces them. With GitHub's protected branch settings you can require a number of approving reviews, passing status checks, approval from the code owners listed in CODEOWNERS, and approval from someone other than the last person who pushed. Nothing then reaches main without a second pair of eyes and a green test run.