Pull Requests and Code Review Workflow

Prerequisites: Git Fundamentals and Branching; a GitHub account; the GitHub CLI (gh) installed.

Targeted versions: GitHub CLI 2.x — run gh --version and gh auth status before starting. This project uses the GitHub CLI for the terminal-first parts of the workflow and the GitHub web UI for the parts the CLI doesn't cover well (visually reviewing a diff, configuring a ruleset). GitHub's current guidance favors rulesets over the older 'branch protection rules' for new configuration — rulesets can layer with each other, target tags as well as branches, and support an Evaluate mode that reports what a policy would block before you turn on enforcement — but classic branch protection rules still function identically for anyone who already has them and you'll see both in the wild. Verified against docs.github.com and cli.github.com, July 2026.

A pull request is often described as a gate that blocks bad code from reaching main — but treating it only that way misses most of its value. A PR is a unit of *conversation* attached to a unit of *change*: the diff, the discussion, the CI status, and the eventual approval all live in one place, which is what makes it possible for a reviewer (or you, six months later) to understand not just what changed but why.

The branch is the payload; the pull request is the conversation about that payload. This project builds the full loop — pushing a branch, opening a PR, reviewing someone else's (or your own, in a second role) PR, and merging only once a review and a policy both allow it. The CI piece — making sure a PR can't merge with failing tests — is deliberately saved for the next project, once you've got the review workflow itself down first.