What is a Pull Request and what is its lifecycle on GitHub?

Think of a Pull Request like submitting a draft article to an editorial team at a newspaper. You write your article (code changes on a feature branch), submit it for review (open a PR), editors leave comments and suggest revisions (code review), the article passes fact-checking (CI status checks), the editor-in-chief approves it (approving review), and it gets published in the next edition (merged to main). The entire editorial process is documented for future reference.

A Pull Request is created when a developer pushes a branch to GitHub and requests that it be merged into another branch, typically main. The PR page shows the diff between the two branches, highlights every file changed, and provides a conversation thread for discussion. Reviewers can leave comments on specific lines of code, suggest changes with GitHub's suggestion feature (which the author can commit directly from the browser), and ultimately approve or request changes. GitHub tracks the review state: pending, commented, approved, or changes requested. The PR also displays status checks from CI systems like GitHub Actions, showing whether tests pass, linting succeeds, and security scans are clean.

The full lifecycle of a PR involves several stages. First, the developer creates the PR with a descriptive title, a body explaining what changed and why, and links to related issues using keywords like 'fixes #42'. Draft PRs can be opened early to signal work-in-progress and get early feedback without triggering notifications to CODEOWNERS. When ready, the developer marks it ready for review. GitHub automatically requests reviews from teams or individuals listed in the CODEOWNERS file based on which files changed. Reviewers examine the diff, leave comments, and approve. Branch protection rules may require a minimum number of approving reviews, passing status checks, and a linear commit history before the merge button becomes available.

In production teams, PRs are the primary quality gate. A payments-api repository might require two approvals from the payments-team, passing unit and integration tests, a security scan from Dependabot or CodeQL, and a successful preview deployment before merging is allowed. Teams choose merge strategies: merge commits (preserves full history), squash and merge (condenses all PR commits into one clean commit on main), or rebase and merge (replays commits linearly). Most teams prefer squash merging for feature branches because it keeps the main branch history clean and each commit on main corresponds to exactly one PR.

A key gotcha is that reviewers sometimes approve a PR, but then the author pushes additional commits after approval. GitHub does not automatically dismiss stale approvals by default, meaning the PR could be merged with unreviewed changes. Enable the 'Dismiss stale pull request approvals when new commits are pushed' setting in branch protection rules to prevent this. Also, large PRs with hundreds of changed files are difficult to review effectively. Keep PRs small and focused on a single concern to get faster, higher-quality reviews.