The pull request workflow on GitHub

A pull request (PR) is a GitHub page that says “please merge branch A into branch B”. It shows the diff, collects review comments, and runs any automated checks you have set up. Most teams protect main so every change arrives through one.

1. Start from an up-to-date main

git switch main
git pull

2. Make a branch and commit

git switch -c feature/search
# ...edit, test...
git add .
git commit -m "Add search box to the header"

Name branches after the work, such as fix/cart-total or feature/search. Smaller PRs get reviewed faster and more carefully.

3. Push the branch

git push -u origin feature/search

-u links your local branch to the remote one, so later you can just type git push.

4. Open the pull request

After the push, GitHub shows a Compare & pull request button on the repository page. Choose the base branch (where it should go, usually main) and the compare branch (yours). With the GitHub CLI you can do it from the terminal:

gh pr create --fill          # title and body from your commits
gh pr create --draft         # open as a draft, not ready for review yet

A good description says what changed, why, and how to test it. Link the issue it solves; writing Closes #42 in the description closes issue 42 automatically when the PR is merged into the default branch.

5. Respond to review

Reviewers leave comments on lines and either approve or request changes. Fix things with new commits on the same branch and push; the PR updates by itself.

git add search.js
git commit -m "Debounce search input"
git push

6. Keep the branch current

If main moves on, bring your branch up to date. Merging is simplest; rebasing gives a cleaner history but rewrites your branch, so it needs a lease-protected force push:

git fetch origin
git rebase origin/main
git push --force-with-lease

If a teammate pushed to your branch in the meantime, --force-with-lease refuses instead of erasing their work. Pull their commits and try again.

7. Merge and clean up

Once checks pass and the PR is approved, press the merge button. GitHub can offer a merge commit, Squash and merge (all commits become one), or Rebase and merge, depending on the repository settings. Then tidy up locally:

git switch main
git pull
git fetch --prune
git branch -d feature/search

After a squash or rebase merge, Git cannot tell that your local branch was merged, because the commits on main are new ones. git branch -d then refuses with not fully merged. Check the PR really is merged, then use git branch -D.

Reviewing someone else's PR

gh pr checkout 123
gh pr view 123 --web

Running the branch yourself catches problems a diff alone hides. When you comment, explain the reason, and mark small style notes as optional so the author knows what blocks the merge.