What is a Pull Request?

The Hook (The "Byte-Sized" Intro)

In 2018, a developer at a fintech company pushed a single-line config change directly to main. No review. No tests. It broke authentication for 200,000 users for 3 hours. Had that change gone through a pull request, a teammate would have spotted the typo in 10 seconds. PRs aren't bureaucracy — they're the last line of defense between your code and production.

📖 What is a Pull Request?

A pull request (PR) — called a Merge Request (MR) on GitLab — is a formal proposal to merge changes from one branch into another. It bundles your code changes with a description, enables line-by-line review, triggers automated tests, and creates a permanent record of every discussion and decision.

Conceptual Clarity

What a PR contains:

Component	Purpose
Title	Summarizes the change in one line
Description	Explains what, why, and how. Links to issues/tickets
Diff	Line-by-line view of every change
Reviewers	People assigned to review the code
CI status	Automated test/build results
Comments	Line-specific and general discussion
Approval	Sign-off before merge is allowed

PR lifecycle:

Create Branch → Commit → Push → Open PR → Review → Address Feedback → Approve → Merge → Delete Branch

Real-Life Analogy

A PR is like submitting a research paper for peer review. You write your paper (branch + commits), submit it to the journal (open PR), reviewers leave comments (code review), you revise based on feedback (push fixups), and once approved, it gets published (merged to main).

Visual Architecture

flowchart LR BRANCH["🌿 Feature Branch"] -->|"Push"| PR["📋 Pull Request"] PR --> REVIEW["👀 Code Review"] PR --> CI["⚙️ CI/CD Tests"] REVIEW -->|"Approved"| MERGE["✅ Merge to main"] CI -->|"Passed"| MERGE style BRANCH fill:#1a1a2e,stroke:#e94560,color:#e94560 style PR fill:#0f3460,stroke:#53d8fb,color:#53d8fb style MERGE fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Quality gate: Every change is reviewed before reaching production.
Knowledge sharing: Reviewers learn about parts of the codebase they didn't write.
Documentation: PR history explains why changes were made — invaluable months later.
CI integration: Automated tests run on every PR, catching bugs before merge.

Code

bash

# ─── Full PR workflow ───

# 1. Create and switch to a feature branch
git switch -c feature/search-bar

# 2. Make changes and commit
git add src/search.js tests/search.test.js
git commit -m "Add search bar with autocomplete"

# 3. Push to remote
git push -u origin feature/search-bar

# 4. GitHub CLI: create PR from terminal
gh pr create --title "Add search bar" \
  --body "Implements search with autocomplete. Closes #42." \
  --reviewer teammate1,teammate2

# 5. After review feedback: push fixes
git add .
git commit -m "Address review: add input validation"
git push
# PR automatically updates

# 6. After approval: merge (or let reviewer merge)
gh pr merge --squash --delete-branch

Writing Great PR Descriptions

markdown

## What
Add search bar with autocomplete to the header.

## Why
Users requested search (Issue #42). Search reduces
navigation time by ~60% based on UX research.

## How
- Added `SearchBar` component using debounced input
- Integrated with existing API endpoint `/api/search`
- Added 12 unit tests covering edge cases

## Screenshots
(attach before/after screenshots for UI changes)

## Testing
- [x] Unit tests pass
- [x] Manual testing on Chrome, Firefox, Safari
- [x] Mobile responsive verified

Key Takeaways

A PR is a formal proposal to merge code — it bundles changes, review, discussion, and CI.
PRs are the primary quality gate in professional software development.
Write clear descriptions: what changed, why, how, and how it was tested.
PR history becomes invaluable documentation of decisions.

Interview Prep

Q: What is a pull request and why is it important? A: A pull request is a formal proposal to merge changes from one branch into another. It's important because it enables code review, triggers automated tests, facilitates discussion, and creates a permanent record of what changed and why.
Q: What should a good PR description include? A: A good PR description explains what was changed, why the change was needed, how it was implemented, any testing done, and links to related issues or tickets. For UI changes, screenshots or recordings are essential.
Q: What is the difference between a Pull Request and a Merge Request? A: They're the same concept — different platforms use different names. GitHub calls them "Pull Requests" (PRs), GitLab calls them "Merge Requests" (MRs). Both propose merging changes from one branch to another with review.

The Hook (The "Byte-Sized" Intro)