Pull Requests: A Mechanism, Not a Workflow

Pull requests are a GitHub-popularized mechanism for coordinating the merge of work into a shared repository, especially in open-source projects. A contributor works on a change in a fork or branch, then sends a request to the maintainer that this work be reviewed and integrated. The tooling that supports pull requests has become central to much of modern software development, yet the practice carries a cost. Critics point out that the added integration friction can undermine the goals of continuous integration.

The Underlying Workflow

The mechanics of a pull request formalize a workflow that existed long before GitHub. The process typically unfolds as:

  1. A contributor begins work on a logical change, often on a branch of the central repository or in a personal fork.
  2. The contributor develops the change as a feature branch, syncing the mainline into their branch as it progresses.
  3. Upon completion, they notify the maintainer, providing a reference to their committed work—be it a branch URL or a set of patches over email.
  4. The maintainer inspects the submission. If revisions are needed, they are communicated back to the contributor, who adjusts the branch or patch set.
  5. Once the changes are acceptable, the maintainer merges, typically via a merge or a rebase.

GitHub's innovation was to make this process seamless. Fork tracking, integrated discussion threads, and automated review-state management became the recognizable interface for this exchange. These conveniences, not the checklist of steps, helped make "pull request" a standard part of the engineering vocabulary.

Assessing Value Through Branching Patterns

To decide whether pull requests are a good fit, it helps to view them through the lens of source control patterns. In that context, pull requests implement a combination of Feature Branching and Pre-Integration Reviews. The value of these patterns depends primarily on your team's social context and trust structure.

Feature Branching is suited for packaging a discrete contribution, allowing it to be reviewed, accepted, or deferred as a unit. It is especially useful when external contributors cannot be given direct commit access. But it carries a cost: less frequent integration with the mainline means more complex merges down the road and a tendency to defer refactoring that crosses branch boundaries.

Pre-Integration Reviews give a team a clear checkpoint for code review, yet they add friction that scales with the speed of the team and the size of the contribution. A stark illustration: one client's data from 2020 showed that 91% of approximately 7,000 pull requests received no comments, yet total waiting time amounted to about 130,000 hours, counting nights and weekends.

Keeping Pull Requests in a CI Environment

The fact that pull requests are engineered around Feature Branches does not preclude their use alongside continuous integration. To make this work, contributions must stay small and the team must be responsive enough that everyone still lands changes on the mainline at least daily. Daily mainline integration is not just merging the current mainline tips into your branch; it requires pulling others' work in continuously and keeping the integration cost manageable.

A practical way to align pull requests with CI discipline is to classify changes by intent. Using a ship/show/ask convention helps a team determine when a direct push suffices, when a branch merits review, and when a pull request is merely informational. Not every change needs approval, and defaulting to pull requests can needlessly throttle delivery.

Review Can Happen Without PRs

The rise of pull requests has broadened the use of code review, largely by giving Pre-Integration Review a home. Code review that catches issues before they reache mainline is beneficial, but it is not the sole way to review code.

Pair programming provides continuous, immediate review during development. Post-integration review is also a viable strategy; a team might log a formal review for each commit or have a tech lead examine particularly risky changes every few days. The most effective form, however, may be Refinement Code Review: the practice of improving existing code whenever a developer looks at it, treating the codebase as a fluid system rather than a text to walk through once. This mindset applies continuously, making code review a natural byproduct of all development work rather than a bottleneck inserted between writing a change and integrating it.

The claim that without pull requests you cannot have code review is simply incorrect. For a significant number of teams, the pre-integration gate they impose is more hindrance than safeguard.