Pull Request or Merge Request¶
Workflow — instantiates Branching and Merging
Creates a reviewable merge proposal with diffs, comments, approvals, checks, and an explicit integration decision.
A pull request turns a merge from a private act into a public, gated proposal. Where the version-control tool can fuse two branches on command, the pull request interposes a checkpoint: the divergence is frozen as a reviewable diff, opened for comment, held against a set of required approvals and automated checks, and merged only when a named authority signs off. Its defining idea is that it makes the integration decision explicit and attributable — nothing enters the mainline without a recorded "who approved this, on what basis, and why." It is the socket into which merge criteria, reviewer authority, and the durable decision record all plug; it does not itself run the tests or resolve the textual conflicts, but it is the gate at which their verdicts are consulted and the moment at which the go/no-go is owned by a person.
Example¶
An outside contributor to an open-source charting library opens a merge request adding a new axis type. The proposal arrives as a self-contained unit: the diff, a description of intent, and a checklist. Automated checks fire immediately — lint, unit tests, a signed-CLA bot — and two of them come back red, so the merge button is disabled by rule, not by anyone's memory. The contributor pushes fixes; the checks turn green. Now a maintainer designated as owner of the rendering module reviews line by line, asks in a comment thread for a smaller public API, and the contributor revises.
Only when the module owner clicks Approve does the rule permitting merge become satisfied. The maintainer merges; the platform stamps the merge commit with the reviewers, the approval, the linked issue, and the full comment history. Six months later, when someone asks why the axis behaves oddly at zero, the entire rationale — who accepted what and the discussion behind it — is one click from the line of code.
How it works¶
- Freeze divergence as a proposal. The branch's changes are pinned as an immutable-for-review diff so reviewers argue over a fixed target, not a moving one.
- Encode the merge rule as gates. Required approvals, required green checks, and branch protections are enforced by the platform: the merge action is mechanically blocked until every condition is met.
- Route to the right authority. Ownership rules (e.g. code-owner mappings) direct the proposal to whoever is accountable for the touched area, so approval is not just anyone's click.
- Persist the decision. The merge writes a durable record — reviewers, approvals, discussion, linked tickets — binding rationale to the resulting mainline state.
Tuning parameters¶
- Required approvals — how many, and from whom. More reviewers catch more, but each added gate slows throughput and can diffuse responsibility.
- Required checks — which automated verdicts block merge. Stricter gates raise quality but make a flaky check a delivery bottleneck.
- Review depth expectation — line-by-line scrutiny vs. lightweight sanity pass. Deep review protects the mainline; heavy review on trivial changes wastes attention.
- Authority model — single owner, any-maintainer, or consensus. Concentrated authority is decisive but a bottleneck; distributed authority is fast but risks inconsistent standards.
- Merge strategy exposed — squash, rebase, or merge-commit on accept, shaping how much branch detail survives in the record.
When it helps, and when it misleads¶
Its strength is that it converts "someone merged something" into an explicit, attributable decision with the reasoning attached — the single richest source of provenance a branch-and-merge system produces, and the point where quality standards actually bite. Its failure mode is the rubber stamp: approval that certifies nothing because no one read the diff. The classic form is bikeshedding[n1] — reviewers spend the thread relitigating a variable name while a genuine defect sails through untouched, because trivial matters are easy to have opinions about and hard problems are not. A related misuse is treating a green check as sufficient — checks prove the gates that exist passed, never that the right gates exist. The guarding discipline is to keep proposals small enough to be reviewed honestly, and to reserve required-reviewer status for people accountable for the area, so an approval is a real assumption of responsibility rather than a reflex.
How it implements the components¶
This mechanism supplies the decision-and-record components; it consumes the mechanical and validation ones from siblings:
merge_rule— required approvals and passing checks are encoded as platform-enforced gates that block merge until satisfied.merge_authority— ownership routing assigns a named person or role responsible for approving, requesting changes, or rejecting.provenance_trace— the merged commit carries reviewers, approvals, discussion, and links: a durable record of what was accepted and why.
It does not create branch identity or the mainline anchor — those come from the Version-Control Branching Workflow — and it does not run the checks it gates on; the Integration Test Suite supplies integration_test, and the standing conflict ledger (conflict_log) belongs to the Merge Conflict Board.
Related¶
- Instantiates: Branching and Merging — the gated integration decision that governs what enters the shared state.
- Consumes: Version-Control Branching Workflow supplies the branch and merge machinery; Integration Test Suite supplies the checks it gates on.
- Sibling mechanisms: Version-Control Branching Workflow · Integration Test Suite · Policy Pilot Reintegration Review · Collaborative Draft Merge Workflow · Design Variant Merge Review · Negotiation Redline Merge · Merge Conflict Board
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Pull Request Or Merge Request operates by moves a frozen change proposal through ownership routing, approvals, checks, and authorized merge. That concrete deployed or enacted form is Protocol, Workflow & Routine under the frozen taxonomy.
Nearest alternative: Assessment, Review & Assurance — Although Assessment, Review & Assurance can support this mechanism, the frozen evidence makes its operative form the act that moves a frozen change proposal through ownership routing, approvals, checks, and authorized merge; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Pull and merge requests arose in collaborative software version-control workflows.
Related originating lineages:
- Organizational & Management Science — Peer review, approval rights, and explicit integration decisions materially shape the coordination process.
Review resolution: Both blind reviewers agree on computer_science as the primary origin. Explicit reconciliation resolves alternate_origin_disagreement, origin_mode_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=specialized records later applicability separately from origin breadth.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Parkinson's law of triviality (popularly "bikeshedding") — the tendency of a group to devote disproportionate attention to trivial, easily-grasped issues while waving through the consequential and hard-to-evaluate ones. In review it is the mechanism by which a formally approved merge can still be effectively unreviewed. ↩