Pull Requests on GitHub

A pull request is a server-side construct (GitHub, GitLab equivalent: 'merge request', Bitbucket: 'pull request'). Internally GitHub creates a refs/pull/<n>/head ref pointing to the PR's branch tip and a refs/pull/<n>/merge ref simulating the merge result. The CLI fetches these on gh pr checkout.

Squash vs merge vs rebase trade-offs: Merge commit preserves the granular history (good for archaeology, noisier git log --oneline). Squash gives one clean commit per PR but loses fine-grained authorship within the branch (good for short PRs, bad for long ones with valuable intermediate steps). Rebase is linear without losing commits but requires no-merge-commit hygiene; conflicts re-trigger per commit on rebase.

Branch protection rules: GitHub main typically has rules — required PRs, required reviews (1+), required status checks (CI green), no direct pushes. Configurable per-branch in repo settings. Bypass requires admin override and is logged.

CODEOWNERS (.github/CODEOWNERS): patterns mapping paths to reviewers. *.tsx @frontend-team auto-requests a review from @frontend-team when a PR touches TSX files. Combined with branch protection ('Require review from Code Owners'), enforces ownership.

Drafts: open a PR as 'Draft' (gh pr create --draft) to share work-in-progress without triggering reviewers. Mark ready when done. CI still runs on drafts unless you skip it.

gh CLI: gh pr create (with --fill for title/body from commits, --web to open browser), gh pr checkout <n> (fetches a PR's branch locally), gh pr review --approve, gh pr merge --squash. Faster than the web UI for power users.