Pull Request
A proposal to merge a branch, carrying review, automated checks, and the discussion around it.
A pull request is a request to merge one branch into another, with a description, a diff, automated checks, and a discussion thread attached. It has become the standard unit of change in collaborative software, largely because it is where review and automation converge.
Its description is a durable artifact, not a formality. On a Squash Merge it becomes the permanent commit message. A useful one states what changed, why, and how it was verified — with the verification claims being genuinely verifiable. A test-plan bullet describing something nobody actually did reads as an observation and is not one, and a reviewer comparing revisions of the description will notice.
Size is the single strongest predictor of review quality. Reviewers engage carefully with small diffs and skim large ones, so a large change gets less scrutiny precisely when it needs more. Splitting into a sequence is the usual remedy; see Stacked Pull Requests.
Two mechanical notes. Changing only the target branch of a pull request does not necessarily re-trigger validation, since the platform's default event set may not include it. And a proposal whose work is visual needs the evidence embedded where the review happens — a path to a local screenshot is invisible on the platform.
See also5
Hand-picked in the note itself — the neighbours worth reading next.
Code Review
A second person reading a change before it lands, and the practices that make it worth the time.
Version Control & Delivery15 connections
Continuous Integration
Automatically building and testing every change, so integration problems surface immediately.
Version Control & Delivery17 connections
Squash Merge
Collapsing a branch's commits into one before merging, trading granularity for a clean main history.
Version Control & Delivery10 connections
Human in the Loop
Requiring a person's judgement at chosen points in an otherwise automated process.
Agents & Language Models9 connections
Branching Model
The convention governing what branches exist, what they mean, and how work reaches production.
Version Control & Delivery11 connections
Related3
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from11
Notes elsewhere in the wiki that reach for this one.
- Atomic CommitVersion Control & Delivery
A commit containing exactly one logical change, complete and independently sound.
- Branching ModelVersion Control & Delivery
The convention governing what branches exist, what they mean, and how work reaches production.
- Code ReviewVersion Control & Delivery
A second person reading a change before it lands, and the practices that make it worth the time.
- Conventional CommitsVersion Control & Delivery
A lightweight convention giving commit messages a machine-readable type and scope.
- Human in the LoopAgents & Language Models
Requiring a person's judgement at chosen points in an otherwise automated process.
- Merge TrainVersion Control & Delivery
Validating changes against the state they will actually merge into, in order, rather than in isolation.
- Semantic ConflictVersion Control & Delivery
Two changes that merge cleanly and are incompatible in meaning.
- Squash MergeVersion Control & Delivery
Collapsing a branch's commits into one before merging, trading granularity for a clean main history.
- Stacked Pull RequestsVersion Control & Delivery
A chain of dependent changes, each reviewed separately and merged in order.
- Trunk-Based DevelopmentVersion Control & Delivery
Everyone integrating into one shared branch continuously, with short-lived feature branches.
- Version ControlVersion Control & Delivery
A system recording the history of a project's files, enabling branching, merging, and recovery.