Understanding Branches and Pull Requests

The pull request is where code review and CI meet - it is the gate every change passes through before merging.

Branches let you isolate work, and pull requests are how you propose merging that work back. Together they form the core unit of change in almost every CI workflow. This lesson explains the model and what CI does at each step.

Why branches exist

Working directly on main means every half-finished change is immediately part of the shared codebase. Branches solve this: you create a feature branch, do your work there, and only integrate when it is ready. The main branch stays clean and releasable while you experiment freely on the side.

What a pull request is

A pull request (PR) is a formal proposal to merge one branch into another, usually your feature branch into main. It bundles your commits with a description, a place for discussion, and - crucially - automated checks. The PR is where teammates review your code and where CI reports whether your change builds and passes tests.

What CI does on a pull request

Builds your branch in a clean environment, catching "works on my machine" issues.
Runs the test suite and reports pass/fail directly on the PR.
Surfaces linting, type, and coverage results as individual checks.
Blocks the merge button until required checks are green (with branch protection).

A typical pull-request trigger

To run CI on pull requests, you tell your workflow to listen for the pull_request event. This is the single most common CI trigger.

.github/workflows/ci.yml

name: CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Key takeaways

Feature branches isolate work so main stays releasable.
A pull request bundles commits, review, and automated CI checks.
The pull_request event is the most common CI trigger.