What a pull request actually is

A concept GitHub invented, not Git

Every merge in the last course happened on the command line. You decided the branch was ready, you ran git merge, and nobody else was involved. That works for a solo project. It breaks down once a second person needs to see the code before it lands on main. "Someone reviews this before it merges" is not a Git feature. It's GitHub's.

The layer GitHub adds on top of Git

A pull request (PR) is a request, hosted on GitHub, to merge one branch into another. It wraps a social and technical layer around the git merge you already know how to run by hand:

              git push
Local branch  ────────▶  Remote branch          Pull Request
(your laptop)             (on GitHub)      ────▶  - shows the diff
                                                    - collects comments
                                                    - runs CI checks
                                                    - gates the merge button

GitLab calls the same thing a "merge request"; Bitbucket also says "pull request". None of it is Git; it's a web application built around Git's branches and diffs.

Why this layer exists

• Code review: a second set of eyes catches bugs, suggests better approaches, and spreads knowledge of the codebase across the team.
• A paper trail: the discussion behind a change stays attached to its diff. A year later, it answers "why was this written this way?"
• Automated gates: CI can run the test suite and refuse to enable the merge button until it passes: catching mistakes before they ever reach main.
• A natural checkpoint: the platform enforces the Branching course's rule that main stays deployable, so it doesn't rest on good intentions.

The shape of the whole cycle

1. Branch off main, do the work        (Branching course)
2. Commit cleanly, push the branch     (Workflow + Remotes courses)
3. Open a pull request                 ← this course starts here
4. Reviewers comment, you respond
5. Checks pass, reviewer approves
6. Merge — via GitHub's button, not your terminal
7. Delete the branch, pull main locally

Steps 1 and 2 are everything the last four courses built. This course picks up where git push left off.

How this course is organized

• Lesson 2: opening a pull request: base branch, description, drafts
• Lesson 3: reading the diff and leaving inline comments
• Lesson 4: responding to feedback: pushing more commits, resolving conversations
• Lesson 5: approvals, required checks and branch protection
• Lesson 6: the three merge strategies GitHub offers, and how they map to what you already know
• Lesson 7: opening, reviewing and merging one real pull request end to end

Key takeaways

• A pull request is a GitHub feature, not a Git one: it wraps a git merge in review, discussion, and automated checks.
• GitLab calls the same idea a "merge request": same concept, different platform.
• The goal is code review, a permanent record of why a change happened, and automated gates before code reaches main.
• This course begins where the last one's git push left off: a branch that exists on the remote, ready to be reviewed.