Pull Request
It's like editing a copy of a class newsletter and handing a note to the editor: 'Please review these changes and add them in.'
Definition A formal proposal in collaborative software development asking to merge changes you made in your own copy into the main codebase. Instead of altering the original project directly, you document what you changed and why so teammates can review and comment. Once it receives the required approvals, your edits are safely integrated into the main project.
Submitting Edits to the Class Newsletter
Imagine your class is putting together a newsletter. There is only a single master draft lying on the teacher's desk. If all thirty students grabbed red pens and tried editing that single draft at once, it would quickly turn into total chaos with nobody knowing who changed what.
So here is what you do instead: you make a photocopy, scribble your edits freely on your copy, and then hand it to the editor with a little note.
On that note, you write things like, 'Fixed a typo in the second paragraph on page 3.' The editor only needs to check the marked spots, making their job much easier. When writing software together, developers use the exact same approach. That note is what we call a proposal to merge changes.
People often abbreviate it as a PR, and depending on the platform, it is also called a Merge Request. The names differ, but the job is identical.
Why Propose Instead of Editing Directly?
The biggest reason is getting an extra pair of eyes. Before your changes touch the master copy, teammates read through them. This review step is called code review, just like an editor reviewing your proposed draft.
Second is the historical record. A pull request clearly highlights every line changed and preserves the entire discussion. If someone wonders months later, 'Why was this written this way?', they can simply look up the original pull request.
Third is safety. Until a pull request is approved and merged, the main codebase remains untouched and stable. Even if you completely rewrite things in your working copy, you won't break anyone else's work.
This is why both companies and open-source projects rely on this process. Anyone can create a copy, make improvements, and submit a pull request for the maintainers to review. It is a safe way to accept help from strangers.
A Closer Look: The Note Is Not the Draft
Back to the newsletter analogy: the note itself is not the article. It is simply a request asking, 'Please review this copy and merge it,' along with the conversation around that request.
More precisely, a pull request is a discussion room tied to your changes. The actual modified code lives in your branch (your copy), and the pull request acts as a window pointing to it. If you make further edits to your branch while the PR is open, the discussion thread updates automatically to reflect your latest work.
One more thing to keep in mind: opening a pull request does not guarantee it will be merged. Reviewers might ask for adjustments, or the team might decide the changes don't fit the project's direction and close the request.
π€ Common misconceptions
Opening a pull request immediately applies your changes to the main codebase.
Submitting a pull request does not change the original code right away. A maintainer must review and approve it before merging. It can also be sent back for revisions or closed without being merged.
Pull requests are only used by professional software engineers inside a company.
Anyone can copy a public open-source project, make improvements, and submit a pull request. Minor contributions like fixing typos or updating translations follow the exact same workflow.
π§Ί Where you meet it
A collaborative workflow where you propose merging changes from your working copy into the main project after peer review, rather than editing the original directly.