Pull Requests — Playbook

In one line

When you write code, there are several ways to branch and merge. This chapter tours the main ones.

Whichever you pick, everyone goes through a Pull Request to merge. We'll break down what a PR contains, and how all of this can be enforced with Rulesets.

Branching strategies

How a team organizes branches around PRs. Pick the model that matches your release cadence.

Strategy	How it works	Best for
🌿 GitHub Flow	One `main` + short-lived feature branches; PR → merge → deploy from `main`	Continuous delivery, most teams
🌳 Git Flow	`main` + long-lived `develop`, plus `feature` / `release` / `hotfix` branches	Scheduled, versioned releases

💡 Default to GitHub Flow for speed; reach for Git Flow only when you ship versioned releases.

GitHub Flow

One long-lived branch (main), short-lived feature branches. Branch off main, open a PR, review, merge, and deploy — continuously. Simple and fast; ideal for web apps and small teams shipping many times a day.

🌿 Branch from main for each change (feature / fix)
🔀 Open a PR early — review and CI run on the branch
✅ Merge to main, then deploy immediately
♻️ main stays always deployable

💡 Fewer moving parts = faster feedback. The default for continuous delivery.

Git Flow

Two long-lived branches (main + develop) plus supporting branches. Work integrates on develop; a release branch stabilizes a version, then merges to main and gets tagged. Structured for scheduled, versioned releases and larger teams.

🌳 develop = integration line · main = production (tagged)
🧩 feature/* branches off develop, merges back
📦 release/* stabilizes → merges to main + develop, tags the version
🚑 hotfix/* off main for urgent prod fixes → merges to both

🎯 More ceremony, more control. Reach for it when you ship versioned releases, not continuous deploys.

Inside a review

Today a PR can be opened by a human, a cloud agent, Dependabot, or an agentic workflow. On the diff, conversation, checks, and automated analysis converge: the place where quality is secured before merge.

Element	Role
🔀 Propose diff	Compare branches, request merge
💬 Review	Line comments, approve/reject
🤖 Copilot code review	AI auto-reviews every PR
✅ Tests / CI	Required status checks must pass
🛡️ Code Scanning (GHAS · Code Security)	CodeQL finds security vulnerabilities
📊 Code Quality (standalone product)	Maintainability & reliability analysis (billed separately)

🔑 Closes #123 in a PR → the Issue auto-closes on merge.

Rulesets

Rulesets enforce merge conditions as rules, a quality gate on your branches. Configure them at the organization or repository level, and apply them top-down across many repos.

Minimal recommended setup:

Rule	Recommended setting	Why
🔀 Require a pull request before merging	ON + Required approvals: 1	Block direct pushes; every change gets at least one review
🛡️ Require status checks to pass	Require tests + Require branches to be up to date before merging	Merge only when CI is green and validated against the latest main
🔍 Require code scanning results	Require CodeQL results (block by severity)	Stop merges while unresolved security alerts remain
🔒 Block force pushes	ON	Prevent destructive history rewrites
🤖 Automatically request Copilot code review	ON	Copilot pre-reviews every PR automatically

🎯 Stop manual gatekeeping; let rulesets enforce top-down.

Stacked pull requests (NEW) 📖 Docs

An ordered chain where each PR targets the branch of the one below it, so reviewers get one small layer at a time instead of a giant diff. Public preview since 2026-07-30.

Merging a stack is one atomic operation. What lands on main depends on the merge method:

Create a merge commit Squash and merge Rebase and merge

Branch commits are kept as-is and the whole stack lands through one merge commit. Fullest history.

Each PR collapses into a single commit on main. Cleanest log, but the individual commits (faded) are lost.

Every commit is replayed onto main in order. Linear history, no merge commit. The originals (faded) are rewritten.

🧱 Branch protections and CI run on every layer, not just the bottom one
🔄 GitHub rebases for you — merge a lower layer and the ones above retarget automatically
☝️ Merge one, some, or all: merging the top PR lands the whole stack, always bottom-up
🛠️ github.com, Mobile, REST / GraphQL / webhooks, and gh extension install github/gh-stack

Agent merge (NEW)

In the GitHub Copilot app, hand a pull request’s last mile to the agent: it clears what is blocking the merge, then merges as soon as GitHub allows.

🔀 Toggle it at the top of a PR — the workspace’s Copilot session picks it up
🩹 Fixes what blocks it: review comments, failing checks, conflicts
🌙 Runs in the background and survives app restarts
✅ Turns itself off once the PR is merged

⚠️ It doesn’t bypass your gates — required approvals and required checks still decide what reaches main.

★ PRs in the AI era

With AI shipping PRs en masse, some ask “are PRs still needed?” But to keep a repo understandable and safe, this gate is necessary.

🤖 Copilot auto-review catches issues early
📈 ~90M merges/month in 2026 (~2x)
👀 Humans approve, AI does the prep

💡 Guard the PR and go faster = Rulesets × Copilot.