A pull request (PR), also called a merge request (MR), proposes integrating code changes into a target branch or repository. It gives reviewers a place to inspect, discuss, comment on, and approve the changes before they are merged. section 2.2.1 section 1.6
A PR is one part of a broader code review: changed code, reviewers, a reviewing mechanism, and a signoff condition. In a PR-centered workflow, opening the PR signals that review is pending, comments carry feedback and discussion, and approval completes the review. section 2.2.1 section 2.2.2
Prepare a PR so that reviewers can understand and evaluate it efficiently:
- Write a clear, concise title and a detailed description containing the context and justification for the change. section 2.5 section 8.2
- Use labels, review states, documentation links, and other agreed information to make the change easy to classify and follow. section 2.5 section 3.4.1
- Break work into manageable, isolated changes; guidance favors chunks of no more than 500 lines that can receive detailed review within about 30 minutes. section 2.5 section 9.2.2
- Agree in advance which issues block approval and which remain nonblocking, then revise those rules as the team encounters new cases. section 3.3.3 section 3.4.1
A missed review
A developer merged an invoice-parsing feature containing incorrect fee calculations and difficult-to-understand code. Without a reviewable change, shared context, and approval before integration, teammates could not reliably diagnose the defect before a CEO demonstration. section 1.0
Figure 2.3 A pull request-based code review workflow
Trace the PR-based review workflow from opening a pull request through pending review, feedback, and approval. section 2.2.2
