Pull Requests & Review

The collaboration layer on top of git — merge strategies, branch protection, and review workflow

Why

Pull requests are where most engineering collaboration actually happens — code review, CI gate, and the final merge decision. Understanding the three merge strategies GitHub offers, and how branch protection rules enforce quality gates, is essential for both day-to-day work and designing team workflows that scale.

Intuition

A PR is not a git concept — it's a GitHub feature layered on top of git. It's a request to merge one branch into another, with a conversation, CI status checks, and review approvals attached. The three merge buttons in GitHub correspond to git merge --no-ff, squash + a single new commit, and rebase onto the base branch.

Explanation

Three GitHub merge strategies

Merge commit

Creates a merge commit with two parents. All original PR commits preserved. History shows branch structure. Best when each commit is independently meaningful.

Squash and merge

All PR commits collapsed into one on the base branch. Clean linear history. The PR becomes one atomic unit — easy to revert. Best for noisy WIP-heavy PRs.

Rebase and merge

Each PR commit replayed onto the base individually. Linear history with all commits preserved (new SHAs). Best when every commit in the PR is clean and meaningful on its own.

Team strategy

Most teams standardise on one strategy per repo. Squash is most common for trunk-based teams. Merge commit is common for GitFlow or when an audit trail matters.

Branch protection rules

Require PR before merging — no direct pushes to main; all changes go through review.
Required status checks — CI (tests, lint) must pass before merge is allowed.
Required reviewers — N approvals needed; dismissed on new commits.
CODEOWNERS — specific teams auto-requested when their files are changed in a PR.
Restrict force push — prevents history rewriting on protected branches.

← Previous Next →