dev-tools
Glossary ↗Pull Request (PR)
A pull request (PR — called a "merge request" on GitLab) is a formal request to merge changes from one Git branch into another, and it's the standard unit around which code review, discussion, and CI checks are organized on platforms like GitHub, GitLab, and Bitbucket. Rather than merging code directly and silently, a developer opens a PR, which shows the full diff of proposed changes, lets reviewers leave inline comments, tracks the status of automated checks (CI, linting, security scans), and maintains a persistent discussion thread — all before the change is allowed to merge into the shared branch. Why it matters for AI/SaaS builders: the pull request is the central coordination point of nearly every modern software team's workflow — it's simultaneously the mechanism for code review, the audit trail for "why was this change made" (via the PR description and linked issue), the gate for CI/CD (branch protection rules typically require passing checks and approvals before merge is allowed), and increasingly the interface where AI participates directly, both as a first-pass automated reviewer and as the output format for AI coding agents (an agent given a task typically concludes by opening a PR for human review, rather than pushing directly to the main branch). How it works: a developer creates a branch off the main branch, commits changes to it, and pushes it to the remote repository. Opening a PR against the main branch triggers CI checks automatically, notifies designated reviewers, and displays the diff for review. Reviewers can approve, request changes, or leave non-blocking comments; once required approvals and checks pass, the PR can be merged (via a direct merge commit, a squash into one commit, or a rebase, depending on team convention), after which the source branch is typically deleted. Worked example: an AI coding agent is tasked with "fix the intermittent test failure in the payments module." It investigates, identifies a race condition in a test's setup code, fixes it, creates a branch `fix/payments-test-race-condition`, commits the change with a descriptive message, and opens a pull request with a description explaining the root cause and fix. CI runs automatically and passes (including 20 consecutive re-runs of the previously-flaky test to confirm the race condition is actually resolved, not just hidden). A human engineer reviews the diff, agrees with the root-cause analysis, approves, and merges — the entire fix went from investigation to production through the exact same reviewable, auditable process a human-authored change would have followed.
Related terms