Definition
Pull Request
A pull request (PR), also called a merge request, is a proposal to merge a set of code changes from one branch into another. It packages a diff with a description, opens it for review and discussion, runs automated checks, and serves as the gate where changes are inspected and approved before they enter the main codebase.
Key takeaways
- A pull request (PR), also called a merge request, is a proposal to merge a set of code changes from one branch into another. It packages a diff with a description, opens it for review and discussion, runs automated checks, and serves as the gate where changes are inspected and approved before they enter the main codebase.
- A pull request is the unit of collaboration in modern version control.
- Planoda links pull requests to the issues they implement via webhooks, so a PR opening, passing checks, or merging can automatically advance the linked issue's status.
A pull request is the unit of collaboration in modern version control. A developer works on a branch, then opens a PR asking to integrate that work. The PR bundles the diff, a title and description explaining intent, and a thread where reviewers comment line by line. It is simultaneously a review tool, a discussion forum, and an integration gate.
PRs are where automation and humans meet. Continuous integration runs the test suite, linters, and security scans on every PR, posting results inline; required checks block a merge until they pass. Reviewers add the human judgment automation can't — is this the right design, does it handle the edge cases, is the intent clear? Only when both the machine and the required reviewers approve does the change merge.
Good PR practice mirrors good change practice: keep them small and single-purpose, write a description that explains the why and how to verify, and link them to the issue they resolve so the history connects intent to implementation. Large, unfocused PRs get rubber-stamped, which defeats the purpose.
Planoda links pull requests to the issues they implement via webhooks, so a PR opening, passing checks, or merging can automatically advance the linked issue's status.
Related terms
- Code ReviewCode review is the practice of having one or more engineers examine a change before it merges, checking for correctness, clarity, security, and adherence to conventions. Beyond catching defects, it spreads knowledge across the team, enforces shared standards, and creates a documented rationale for why code looks the way it does — typically conducted on a pull request.
- CI/CD (Continuous Integration / Continuous Delivery)CI/CD is the practice of automatically building, testing, and releasing code through a pipeline triggered by every change. Continuous integration merges and verifies work frequently to catch conflicts early; continuous delivery keeps the software always in a releasable state, often deploying automatically. Together they shorten the path from a commit to running in production.
- Feature FlagA feature flag (or feature toggle) is a runtime switch that turns a piece of functionality on or off without deploying new code. It decouples deployment from release, letting teams ship code dark, roll a feature out gradually, target specific users, run experiments, and instantly disable a problem — all through configuration rather than a redeploy.
- Issue TrackerAn issue tracker is the system of record for a team's work — every bug, feature, and task captured as a structured issue with a state, assignee, priority, and history. It replaces scattered emails and spreadsheets with one searchable, accountable source of truth that the whole team plans, executes, and reports against.
- WebhookA webhook is an automated HTTP request a system sends to a URL you provide whenever a specified event occurs — an issue created, a status changed, a comment added. Instead of repeatedly polling an API for changes, your service receives a real-time push. Webhooks are the backbone of integrations, letting tools react to each other instantly.