A pull request is a proposal to merge code changes into a project. In GitHub’s own words, “Pull requests are proposals to merge code changes into a project.” Rather than pushing changes straight into a shared codebase, a contributor works on a separate branch or a personal fork and then asks the project to “pull” those changes in, opening the proposal up for inspection first.
The mechanism has its roots in distributed version control. In a system like git, every clone of a repository is a full copy, and one developer can ask another to pull commits from their copy. The pull request takes that low-level idea and wraps it in a structured, social workflow: a named proposal with a discussion thread, a view of exactly which files changed, and a record of the back-and-forth that led to the final code.
Crucially, the pull request became the home for code review. GitHub described pull requests as “living discussions about the code you want merged,” interleaving review comments, follow-up commits, and automated checks into a single conversation. Reviewers comment on specific lines, contributors push fixes in response, and continuous-integration tests report whether the change passes, all before anything is merged.
The pull request works both for outside contributors sending changes from a fork and for teammates collaborating within one shared repository. As GitHub noted, the model is “just as useful in scenarios where a team is working out of a single shared repository as they are in the fork + pull model.” That flexibility is why the pull request, popularized by GitHub and adopted by Bitbucket, GitLab, and others, became the default unit of collaboration in modern software development.