Lesson 0.4 · Pull Requests

Story

Building-a-house world — same site and crew as every Phase 0 lesson.

You finished a sample build off to the side (that was lesson 0.3 — a branch). It looks great. But you don't just bulldoze it into the real house yourself.

You bring the work to the approval desk. The inspector and you (the owner) stand there and look at exactly what changed — before-and-after photos, side by side. Someone says "move that socket 10cm left." The crew fixes it. Everyone nods. Then the work gets joined to the real house.

That approval-desk step — show the work, review it, then join it — is a pull request.

The idea

A pull request (PR) is a formal request to merge the commits from one branch into another (usually your side branch → main). It's not just the merge — it's the approval desk around the merge, where review happens.

Every PR has:

A base branch and a head branch. Base = where the work will go (the real house, usually main). Head = where it comes from (your sample build / branch).
A title + description — what changed and why.
The diff — the before/after photos. Green = added, red = removed.
Reviews — people or bots read the diff and respond.
Checks — the automatic inspection rig (Actions, lesson 0.6) runs and shows green ✓ / red ✗.
A merge button — only safe to press once reviews + checks are happy.

A draft PR = "still building, don't review/merge yet."

Real example — the syntax teaser

You rarely build a PR by hand on the exam, but recognize how one is created and merged.

In the browser: push your branch → GitHub shows a "Compare & pull request" button → fill title/description → "Create pull request." Reviewers click Files changed (the diff) and Conversation (reviews). The big green button at the bottom is the merge.

From the terminal (GitHub CLI) — recognize these:

# create a PR from your current branch into main
gh pr create --base main --title "fix: empty cart crash" --body "Closes #42"

# after approval + green checks, merge it (pick ONE method — see below)
gh pr merge --squash      # also: --merge  or  --rebase

Closes #42 in the body auto-closes issue 42 when the PR merges (lesson 0.5).

source: cli.github.com/manual/gh_pr_merge · fetched 2026-05-28

The three merge methods — what's different, when to use which

The part most explainers skip. The merge button has three modes, and each shapes your history (the build diary from 0.2) differently.

1. Merge commit (the default)

Does: "All commits from the feature branch are added to the base branch in a merge commit" (uses --no-ff).
History: keeps every commit + an extra "merge" entry. Branchy.
Use when: you want the full story — every step, plus the fact a branch happened.

2. Squash and merge

Does: "The pull request's commits are squashed into a single commit."
History: many messy commits → one clean commit. Linear.
Use when: your branch has lots of "wip" / "fix typo" commits not worth keeping. Most common for feature PRs.

3. Rebase and merge

Does: "All commits… are added onto the base branch individually without a merge commit" (re-writes history).
History: each commit kept, but no merge entry. Linear.
Use when: you want each commit preserved AND a straight line. Avoid on long-running branches.

The difference, in one look

First, the thing that trips everyone up: all three methods put your branch's work onto main. Every one. They differ only in the shape main's history takes afterward. A "merge commit" is just an extra bookkeeping line saying "a branch joined here" — skipping it does not mean the work wasn't merged.

Say main had commits A, B; your branch added C, D, E:

start:   main: A-B
                  \
                   C-D-E         (your branch)

merge:   A-B---------M           C-D-E kept on a side path,
            \       /            M = the join-knot (extra entry)
             C-D-E

squash:  A-B-S                   C+D+E squashed into ONE commit S

rebase:  A-B-C-D-E               C,D,E copied FLAT onto main, no knot

Merge commit vs rebase — both keep your 3 commits, but merge-commit leaves a visible fork + a knot (M); rebase lays them flat on main, no knot. That's the difference — merge is not a straight line.
"No merge line" ≠ "not merged." With squash and rebase the work still lands on main — there's just no extra "merged branch" entry. Rebase copies your commits onto the tip of main; the old side branch can then be deleted.

One sentence: squash = 3 become 1 · rebase = 3 laid flat on main · merge = 3 kept on a side path with a join-knot.

What if `main` moved too while you worked? (diverged branches)

The picture above assumed main sat still. Usually it doesn't — a teammate pushes a commit F to main while you do C-D-E. Now both have moved past B (they've diverged):

main: A-B-F
         \
          C-D-E        (your branch)

What each method does now:

merge:   A-B-F------M     M ties F + your E together — both kept
            \      /
             C-D-E

squash:  A-B-F-S         your C+D+E squashed on top of F

rebase:  A-B-F-C-D-E     your commits REPLAYED on top of F
                         ("re-base" = move your start from B to F)

That's literally where the name comes from: rebase changes the base of your commits from B to the new tip F.

Conflicts: if F changed the same lines you did, you resolve them — once at the knot (merge), or per commit as each replays (rebase). That per-commit pain is why you avoid rebasing long-running branches.

Repo setting: squash and rebase each must be allowed in repo settings ("The repository must allow squash merging" / "…rebase merging"); merge commit is on by default.

source: docs.github.com/.../about-pull-request-merges · fetched 2026-05-28

Relevance

Merge methods → Exam: LOW · Day-to-day: HIGH. GH-600 is unlikely to drill the exact button (it cares far more about the review + checks gate below) — so for the exam, just recognize the three names. But you'll use this constantly as a developer, so the diagram above is worth truly understanding. When exam-weight and daily-work-weight differ, we say so — and go deep when either is high.

Review responses — and when each is used

A reviewer gives one of three responses (these are worth knowing):

Comment — feedback, no verdict ("why this approach?"). Doesn't approve or block.
Approve — "ship it." Counts toward a required-approval rule (lesson 0.9).
Request changes — "fix this first." Blocks merge until resolved.

Why this matters for GH-600

The PR is the control point for AI agents — the whole cert safety model runs through it. "Agents propose; humans and policy accept":

Agent works on a branch → opens a PR. ← the propose
Checks run automatically (Actions: tests, lint, security).
A human reviews the diff → Approve or Request changes. ← the accept
Only then → merge.

GitHub Copilot's coding agent works exactly this way: you give it an issue, it works on a branch, it opens a PR for you to review. The agent's output is a proposal sitting at the approval desk — not a change forced onto the house.

Exam relevance

PR-as-control-point: HIGH. That an agent's work arrives as a reviewable PR gated by checks + human approval is core GH-600. Know base/head, the three review responses, and that the PR is where the human stays in the loop.

Check-in — three quick questions

Open-ended. Think first, then peek at the suggested answer.

In one sentence — what is a pull request, and what's the difference between its base and head branch?

Suggested answer

A pull request is a request to merge the commits from one branch into another, with review in between. The head branch is where the changes come from (your side branch); the base branch is where they'll go (usually main).
(carryover from 0.3) An AI agent finished a risky change on a branch. What does it do next to get into main, and who/what decides if it merges?

Suggested answer

It opens a pull request (the propose step). Automated checks run, and a human reviews the diff — approving or requesting changes. It merges only when checks pass and a reviewer approves (often enforced by branch protection). Agents propose; humans and policy accept.
Squash vs merge-commit: what's the difference in the history each leaves behind?

Suggested answer

Squash collapses all the branch's commits into a single clean commit on main (linear history). A merge commit keeps every individual commit plus an extra merge entry, preserving the full branching story.

Mentor marks this lesson verified after you compare answers and say "got it" in chat.

I've finished this lesson — mark it complete

Ticks this lesson done on the home roadmap. Saved in this browser.

Sources: docs.github.com — about pull requests · merge methods · gh pr merge · Copilot coding agent · fetched 2026-05-28.

Unofficial study material. Not affiliated with, endorsed by, or sponsored by GitHub or Microsoft. “GH-600” and “GitHub” are trademarks of their respective owners, used for identification only.