Pull Request

Software is rarely created alone. Often many people work simultaneously on the same files of a program. So that no one overwrites each other’s work, the official state of the program is kept in a central location. Anyone who wants to change something first works on their own copy. Once finished, they submit the change as a proposal: this is a pull request, or PR for short. The name literally means “request to take over” — the maintainers decide whether the proposal moves into the official version.

PRs as a quality gate for code

A PR is the point where mistakes are caught before they cause damage. At least one other person reads the change and asks questions. This four-eyes principle is called code review in the industry. Studies and experience show: many bugs are discovered early this way and are still cheap to fix at that stage.

Almost as important is the documentation. Every PR contains a description, a discussion, and the exact comparison of the old and new state. Anyone who wants to know years later why a line looks the way it does will find the reasoning there. In large projects, that amounts to hundreds of thousands of traceable decisions.

For companies, this also has a legal dimension. In regulated fields such as banking or medical technology, it must be verifiable who reviewed and approved a change. The PR automatically provides this evidence. That’s why it has long since ceased to be merely a tool for programmers and has become part of corporate processes.

From branch to merge

It all starts with what’s called a branch, a separate side track of the project. There, you’re free to experiment without endangering the working main version. You can picture it like a photocopy of a text that you write into. Only once the version is convincing should it replace the original.

The PR opens up the discussion about this. On platforms like GitHub or GitLab, you can see line by line what was deleted and what was added. Others leave comments directly on the relevant line. The author incorporates the feedback and uploads an improved version.

In parallel, automated checks run. Test programs verify that the software still does what’s expected and flag formatting errors. Once all checks pass and approval has been given, the merge follows: the change is inserted into the main version. In case of conflicts — that is, when two people have changed the same line — the author must manually decide which version prevails.

PRs in open source and with AI assistants

Pull requests are most visible in open-source projects, whose program code is publicly viewable. Anyone who finds a bug in a free app can submit a fix themselves. Large projects thus receive contributions from strangers every day. An accepted PR in a well-known project counts as solid proof of skill in job applications.

In tech news, the term often comes up in connection with AI coding assistants. Tools like GitHub Copilot or Claude Code now handle tasks independently and submit the result as a PR. This turns the human from writer into reviewer. That’s exactly what’s being debated: if a machine produces hundreds of PRs, who still reads them carefully?

One mix-up is worth mentioning. In the business section, “PR” usually stands for public relations. In software contexts, it almost always means pull request. At GitLab, by the way, the same procedure is called a merge request — the process is identical, only the name differs.