The pull request workflow

The pull request (PR) is the industry ritual for proposing a change, getting it reviewed, then merging it. This lesson covers the full cycle, seen from GitHub.

Why pull requests exist

Pushing directly to main is risky on a shared project. A PR creates a discussion space around your changes: others can read the diff, leave comments, and request modifications. Nothing lands in main without being reviewed first.

Even when working solo, opening a PR is a good habit: it forces you to re-read your own diff before merging.

Step 1: create a branch and push

$git switch -c fix/typos-readme

Make your changes and commit them:

$git add README.md
git commit -m "fix typos in README"

Push the branch to GitHub:

$git push -u origin fix/typos-readme

Step 2: open the PR on GitHub

After pushing, GitHub often shows a "Compare & pull request" banner. Otherwise, go to the Pull requests tab and click New pull request.

Select:

• base: the target branch, usually main.
• compare: your branch fix/typos-readme.

Write a clear title and a description explaining the why (not just the what). Then click Create pull request.

Step 3: the review

Reviewers read the diff in the Files changed tab and add line-by-line comments. To address feedback, edit your code, commit, and push again to the same branch. The PR updates automatically.

$git add README.md
git commit -m "address review feedback"
git push

Step 4: merge

When the PR is approved, you (or the maintainer) click Merge pull request on GitHub. GitHub offers three modes:

• Create a merge commit: keeps the full history with a merge commit. The default.
• Squash and merge: squashes all PR commits into one before merging. Cleaner history.
• Rebase and merge: rebases the commits onto main without a merge commit. Linear.

After merging, delete the branch on GitHub (the "Delete branch" button).

Locally, update main and delete the local branch:

$git switch main
git pull
git branch -d fix/typos-readme