Explaining developer jargon for everyone else: “Pull Request”

Before a pull request makes sense, you need to know a tiny bit about how developers store their code.

All the code for a project lives in a repo (more on that in the monorepo post). Think of it like a shared Google Doc for code — except instead of everyone editing the same document simultaneously, developers work on their own separate copies and then carefully merge their changes back in.

That shared, official version of the code is called the main branch.

When a developer starts working on something new (a feature, a bug fix, whatever) they create a branch. A branch is essentially a private copy of the code where they can make changes without affecting the main version that everyone else is working from.

It’s like making a copy of that Google Doc to draft your edits in, so you don’t accidentally mess up the original while you’re still figuring things out.

When a developer is done with their changes on their branch, they need to get those changes back into the main branch. That’s where a pull request comes in.

A pull request (often just called a PR) is a formal proposal to merge your changes into the main branch. The name comes from asking the team to “pull” your changes in.

But more than just a merge button, a PR is a structured way for the team to review the changes before they go live. Teammates can look through the code, leave comments, ask questions, and request changes. It’s a safety net.

1. Developer makes changes on their branch.
2. Developer opens a PR. This notifies the team that changes are ready for review.
3. Teammates review the code and leave feedback.
4. Developer addresses any feedback and updates the PR.
5. Once everyone’s happy, the PR gets merged and the changes officially become part of the main branch