What is a Pull Request (PR)?

A Pull Request (PR) — also called a Merge Request (MR) in GitLab — is a formal request to merge code changes from one branch into another within a version control repository. It is the primary mechanism for code collaboration in modern software development, enabling teams to review, discuss, and approve changes before they are integrated into the main codebase.

According to the 2024 State of DevOps Report by DORA (DevOps Research and Assessment), teams with effective code review practices through pull requests experience 25% fewer change failures and 30% faster recovery times when incidents occur. A study by SmartBear found that code review catches 60-90% of defects before they reach production, making PRs one of the most cost-effective quality assurance practices.

As Martin Fowler notes: "Code reviews, done well through pull requests, are one of the most effective ways to improve code quality and share knowledge across a team. The key word is 'done well' — a rubber-stamp approval adds no value."

The PR Workflow

The standard pull request workflow follows these steps:

1. Create a branch: Developer creates a feature branch from the main branch
2. Make changes: Write code, add tests, update documentation
3. Push the branch: Push changes to the remote repository
4. Open a PR: Create a pull request with a title, description, and reviewers
5. Automated checks: CI/CD pipeline runs tests, linting, and other checks
6. Code review: Teammates review the code and provide feedback
7. Address feedback: Author makes requested changes and pushes updates
8. Approval: Reviewers approve the changes
9. Merge: The branch is merged into the target branch
10. Cleanup: The feature branch is deleted

Branching Strategies

The branching strategy determines how PRs flow through the repository:

Research from DORA shows that trunk-based development with short-lived branches (less than 1 day) correlates strongly with high-performing engineering teams.

The terms are functionally identical but used on different platforms:

The term "pull request" originates from the Git concept of "pulling" changes from one branch into another. GitLab chose "merge request" as a more intuitive description of the action being performed.

PR Title

A good PR title is concise and descriptive:

• Good: Add user authentication via OAuth 2.0
• Good: Fix: Cart total not updating after item removal
• Bad: Update code
• Bad: WIP changes

Many teams adopt Conventional Commits format for PR titles:

• feat: Add dark mode toggle to settings
• fix: Resolve memory leak in WebSocket handler
• refactor: Extract payment logic into service class
• docs: Update API documentation for v2 endpoints
• test: Add integration tests for checkout flow

PR Description

An effective PR description includes:

1. What: Summary of the changes
2. Why: Context and motivation (link to issue/ticket)
3. How: Technical approach and key decisions
4. Testing: How the changes were tested
5. Screenshots: For UI changes, before/after screenshots
6. Checklist: Verification items (tests pass, docs updated, etc.)

PR Description Template

## Summary Brief description of what this PR does. ## Related Issue Closes #123 ## Changes - Added X component - Updated Y service - Removed deprecated Z method ## How to Test 1. Navigate to /settings 2. Toggle dark mode 3. Verify all pages render correctly ## Screenshots | Before | After | |--------|-------| | [img] | [img] | ## Checklist - [ ] Tests pass - [ ] Documentation updated - [ ] No breaking changes

One of the most impactful factors in code review effectiveness is PR size.

Research on PR Size

A landmark study by SmartBear analyzing 10 million code review sessions found:

• Review effectiveness drops dramatically after 200-400 lines of code
• Reviewers can effectively review about 400 lines of code per hour
• Beyond 400 lines, defect density found by reviewers drops by 50%
• Reviews longer than 60 minutes show significantly diminished returns

Google's engineering practices recommend that "small PRs are almost always better" and set soft guidelines around 200-300 lines per review.

PR Size Guidelines

Strategies for Smaller PRs

• Stacked PRs: Break a feature into sequential PRs that build on each other
• Feature flags: Deploy incomplete features behind feature flags to enable smaller merges
• Refactoring first: Submit refactoring changes separately from feature changes
• Interface-first: Define interfaces/contracts first, implement later

For Reviewers

1. Review promptly: Aim to provide feedback within 4 hours during work hours. Google's internal data shows that teams with faster review turnaround have higher developer satisfaction
2. Be constructive: Frame feedback as suggestions, not commands. "Consider using X because..." vs. "This is wrong"
3. Distinguish severity: Clearly indicate what's blocking vs. a suggestion vs. a nit
4. Focus on what matters: Architecture, logic bugs, security issues > style preferences
5. Approve when "good enough": Don't block PRs for minor style preferences
6. Ask questions: If you don't understand something, ask rather than assume it's wrong
7. Praise good work: Acknowledge clever solutions or clean code

For Authors

1. Self-review first: Review your own PR before requesting others
2. Keep PRs small: Smaller PRs get faster, better reviews
3. Write a good description: Help reviewers understand context
4. Respond to all comments: Even if just "Done" or "Good point, fixed"
5. Don't take it personally: Review feedback is about the code, not you
6. Be responsive: Address feedback promptly to keep the PR moving

Common Review Conventions

Modern PR workflows include automated checks that run before human review:

CI/CD Pipeline

• Build: Verify the code compiles successfully
• Unit tests: Run automated test suite
• Integration tests: Verify component interactions
• Linting: Check code style and formatting
• Static analysis: Detect potential bugs and code smells
• Security scanning: Identify vulnerabilities (SAST/DAST)
• Coverage: Ensure test coverage meets thresholds

GitHub Actions Example

name: PR Checks on: pull_request jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm install - run: npm test - run: npm run lint

Branch Protection Rules

Most platforms support rules that prevent merging without:

• Required number of approvals (typically 1-2)
• Passing CI/CD checks
• Up-to-date branch with target
• Resolved conversations
• Signed commits

Key Metrics

• PR Cycle Time: Time from PR open to merge (target: < 24 hours)
• Time to First Review: Time until the first review comment (target: < 4 hours)
• Review Iterations: Number of review rounds needed (target: 1-2)
• PR Size: Average lines changed per PR (target: < 400)
• Merge Frequency: PRs merged per developer per week
• Review Load: Number of reviews per developer per week

Industry Benchmarks

According to LinearB's Engineering Benchmarks report (2024):

Draft PRs

Open a PR early in draft/WIP state to:

• Get early architectural feedback
• Signal to the team that work is in progress
• Run CI/CD checks during development
• Enable collaborative development

Stacked PRs

Break large features into a chain of dependent PRs:

main ← PR1 (data model) ← PR2 (API) ← PR3 (UI)

Each PR is small and reviewable, and they merge sequentially. Tools like Graphite and ghstack help manage stacked PRs.

Auto-merge

Configure PRs to merge automatically when all checks pass and required approvals are obtained. This reduces merge queue wait times.

Merge Queue

For high-traffic repositories, a merge queue ensures that PRs are tested against each other before merging, preventing "merge skew" where individually passing PRs conflict when combined.

Pull requests are the lifeblood of open-source collaboration:

• Fork and PR: Contributors fork the repository, make changes, and submit a PR
• Contribution guidelines: Projects define standards in CONTRIBUTING.md
• CLA/DCO: Some projects require legal agreements before accepting PRs
• Maintainer review: Project maintainers review and merge community contributions

Major open-source projects like Linux, Kubernetes, and React receive thousands of PRs monthly, making effective PR processes essential.

What's the difference between a PR and a commit?

A commit is an individual unit of change saved to the repository. A PR is a request to merge one or more commits from a branch into another branch. A single PR typically contains multiple commits.

Should I squash commits when merging?

It depends on team preference. Squash merge creates a clean history with one commit per PR. Merge commit preserves the full commit history. Rebase merge creates a linear history. Most teams prefer squash merge for cleaner git logs.

How many reviewers should a PR have?

Research suggests 1-2 reviewers is optimal. More than 2 reviewers shows diminishing returns — the additional reviewers tend to find the same issues. Google requires 1 approval; many teams require 2 for critical code paths.

What should I do if a PR has been open for too long?

If a PR is open for more than 48 hours without review, escalate politely. Mention it in daily standup, send a direct message, or use tools that track review SLAs. Stale PRs accumulate merge conflicts and slow the team.

Can I merge my own PR?

Some teams allow self-merge after approval. Others require a different person to click the merge button. The key is that at least one other person has reviewed and approved the code.

How do I handle merge conflicts in a PR?

Rebase your branch onto the latest target branch (git rebase main) or merge the target into your branch (git merge main). Resolve conflicts locally, test, and push. Regular rebasing prevents large conflict accumulations.

• CI/CD — Continuous Integration / Continuous Delivery
• Git — Version control system
• DevOps — Development and operations culture
• Code Review — Peer review of code changes
• Feature Flag — Toggle features without deployment
• Trunk-Based Development — Branching strategy