Production is down.

The build was green. The pull request was approved. CI passed. The branch was protected.

And yet, here we are. Someone says it.

"But you merged it."

It's not shouted. It's not even hostile. But it reveals something. Responsibility has moved. Not legally, not formally. Culturally. And that shift didn't happen by accident. It was designed into our workflow.

This article continues the theme from Cargo Culting in Software Development: A Quick Introduction. Pull requests are not inherently bad, but the way many teams use them often resembles ritual more than reasoning.

---

Where Pull Requests Actually Come From

To understand how we got here, we need to rewind. Not to GitHub. Further back.

The Linux Kernel

The modern pull request workflow descends from the development process of the Linux kernel. In the early 2000s:

• Thousands of contributors.
• Globally distributed.
• No shared employer.
• No shared Slack.
• No shared roadmap.
• No default trust.

Contributors sent patches via email to subsystem maintainers. Maintainers reviewed them inline. Long discussion threads unfolded on mailing lists. Eventually, trusted maintainers sent pull requests upstream.

In 2005, after the BitKeeper licensing dispute, Linus Torvalds created Git. Git was optimized for:

• Distributed development.
• Patch exchange between trusted maintainers.
• Cryptographic integrity.
• Long-lived branches.
• Asynchronous review.
• Hierarchical trust networks.

Git was not designed for:

• Centralized dashboards.
• Button-driven approvals.
• Mandatory protected branches.
• Green checkmarks.

It was a tool for a very specific environment: a large, adversarial, loosely coordinated ecosystem. In that context, gatekeeping was not bureaucracy. It was survival.

Then Came GitHub

In 2008, GitHub wrapped Git in a web interface. And it did something culturally massive: it turned "please pull my branch" into a button. Create Pull Request.

This abstraction did three things:

1. Centralized collaboration.
2. Made review visible and structured.
3. Introduced a merge ceremony.

Slowly, quietly, it normalized a workflow. The pull request became:

• The place where code "happens."
• The gate before legitimacy.
• The unit of review.
• The ritual before integration.

It made sense in open source. But then something else happened. Every 5-person startup adopted it. Every internal team adopted it. Every side project adopted it. Not because they faced Linux's trust problem, but because it was the default.

---

Cargo Culting the Merge Button

Pull requests were born in an environment of:

• Unknown contributors.
• Long patch series.
• Subsystem guardians.
• Adversarial inputs.
• High architectural inertia.

Most product teams operate in an environment of:

• 4–12 known engineers.
• Shared goals.
• Daily communication.
• Short-lived branches.
• Fast iteration.
• Cheap reverts.

Yet we copy the ritual. Protected main branches. Mandatory reviews. Green checks required. Restricted merge permissions. We inherited the ceremony — without asking whether we inherited the problem.

The Real Cost of PR-Based Workflows

This is not a philosophical objection. It's economic.

PR Pileup

Small teams accumulate PRs. Five developers, fifteen open pull requests. Some waiting for review. Some waiting for CI. Some outdated. Some rebased three times already.

Context switching explodes. Review fatigue sets in. And changes grow larger to "justify" the process. The system incentivizes batching. Batching increases risk. Risk increases review overhead. Review overhead increases latency. Latency increases batching. It's a loop.

Review Overhead

A pull request is not just code. It is:

• Branch creation.
• CI run.
• Review request.
• Waiting.
• Comments.
• Fix commits.
• Re-review.
• Merge.

Multiply that by dozens of changes per week, then multiply by team size. Very few teams measure this cost, but they feel it.

PR Rot

The longer a PR sits, the more the trunk moves.

Tests change. Dependencies shift. Architecture evolves. Requirements adjust.

By the time the PR merges, it was reviewed against a world that no longer exists. And we still say: "It was approved." Approval is a snapshot. Reality is continuous.

---

Responsibility Drift

Now back to that sentence.

"But you merged it."

Formally, the author owns the code. But culturally? The merge button changes how responsibility feels.

In PR-based workflows:

• The author writes.
• The reviewer approves.
• Someone clicks the button.
• CI validates.
• The branch is protected.

Responsibility diffuses across the ritual. When something breaks, it's rarely "I wrote it. I'll fix it." It's often:

"But it was reviewed." "But it passed CI." "But you merged it."

The system subtly trains us to distribute ownership. Shared responsibility sounds collaborative. In practice, it often weakens accountability.

Trunk-Based Development Feels Different

In trunk-based systems, there is no ceremonial merge. You push. Your name is on the commit. The build fails? You fix it. Production breaks? You investigate. Responsibility is sharp, immediate, personal.

That doesn't mean no review happens. It means review is continuous. Commits can be:

• Reviewed after push.
• Discussed inline.
• Read in batches.
• Inspected in code-reading sessions.
• Explored during pairing.

Review becomes advisory, not gatekeeping. Integration happens immediately. Correction happens quickly. The feedback loop shrinks.

When Pull Requests Make Sense

Pull requests are excellent when:

• Contributors are unknown.
• Codebases are massive.
• Subsystems have long-lived guardians.
• Legal traceability matters.
• Safety certification requires formal review.
• Architecture is difficult to revert.

In those environments, the gate is a feature. But in high-trust, fast-moving software teams:

• Reverts are cheap.
• CI is fast.
• Communication is instant.
• Developers are accountable.
• Features are reversible.

The main risk is not sabotage. It's latency.

A Brief Aside: Merge vs Rebase

At this point, someone will ask:

“Should we squash?” “Should we rebase?” “Should we forbid merge commits?” “Should history be perfectly linear?”

These discussions matter.

But they often dominate teams that integrate rarely and in large chunks.

When integration is heavy, history shape feels important. When integration is continuous, it barely registers.

Clean graphs don’t reduce risk. Short feedback loops do.

We can debate merge vs rebase another time.

The more interesting question is:

Why is integration infrequent enough that history aesthetics feel critical?

---

The Real Question

Most teams never explicitly choose their workflow. They inherit it. GitHub makes PRs the default. Protected branches feel professional. Green checks feel safe. Approval feels responsible.

But workflow is a system, and systems shape behavior. If your team frequently says "But you merged it," then something has shifted. Responsibility has become ceremonial. And perhaps you copied a solution designed for strangers into a team built on trust.

Closing Thought

The Linux kernel needed pull requests. It operates at global scale with distributed trust. Your five-person software team does not.

Before you protect main, before you require approvals, before you add one more CI gate. Ask a simple question: what problem are we solving?

If the answer is "This is how it's done," you may not be practicing best practice. You may be maintaining a ritual. And rituals, without context, are cargo cults.