Pull Requests and Code Review

A pull request (PR) — called a merge request on GitLab — is not a Git primitive at all; it is a feature of hosting platforms like GitHub, GitLab, and Bitbucket that wraps a Git operation (merging one branch into another) in a collaborative review workflow. Under the hood a PR is just a comparison between two refs, typically a feature branch and a target branch such as main. What makes it powerful is everything the platform layers on top: a diff view, threaded comments on specific lines, required status checks, approval rules, and a merge button that only becomes active once the team's policies are satisfied. Understanding this separation matters because it explains why you can git merge locally without ever touching a PR, and why a PR can sit open for days accumulating commits and conversation before the underlying merge actually happens.

A good PR starts before the first commit — you push a branch, open the PR early (often as a draft), and let the description do real work. The description should state what changed, why, how it was tested, and any risk or rollout considerations; screenshots and before/after output matter for UI or CLI-facing changes. Small, focused PRs are dramatically easier to review than sprawling ones: a 100-line diff that does one thing gets thorough scrutiny, while a 2,000-line diff touching five subsystems gets skimmed. Many teams enforce this culturally by asking contributors to split unrelated changes (a refactor plus a feature) into separate PRs.

Reviewing is a skill distinct from writing code. Effective reviewers read for correctness first (does this do what it claims, are edge cases handled, are tests meaningful), then for maintainability (naming, structure, whether the change fits existing patterns), and only last for style — and even then, style nits are best automated away with linters and formatters so humans don't spend review time on semicolons. Comments should be specific and actionable: 'this will throw if items is empty, add a guard' is useful; 'this looks off' is not. Distinguishing blocking comments from optional suggestions (many teams prefix nits with 'nit:' or use suggestion comments) keeps review from stalling on non-essential feedback.

Most platforms offer three ways to land a PR: a regular merge commit (preserves every commit and creates a merge commit recording the join), a squash merge (collapses all commits on the branch into a single commit on the target branch, keeping history linear), and a rebase merge (replays the branch's commits individually onto the target with no merge commit at all). Squash merging is popular for feature branches with messy work-in-progress commits because the target branch ends up with one clean, reviewable commit per PR; teams that value granular history or use conventional commits per logical change often prefer rebase merges instead.