GitHub Pull Requests and Merges

Prerequisites

• •GitHub CLI (gh) installed and authenticated: gh auth login

Creating a Pull Request

From current branch (after push)

gh pr create

Interactive prompts for title, body, base branch, and reviewers.

Non-interactive

gh pr create --title "feat: add X" --body "Description of changes" --base main

From a branch without pushing first

gh pr create --fill   # Uses commit messages for title/body; pushes if needed

Draft PR

gh pr create --draft

Reviewing a Pull Request

Check out a PR locally

gh pr checkout <pr-number>
# or
gh pr checkout 42

View PR details

gh pr view <pr-number>
gh pr view --web   # Open in browser

List PRs

gh pr list                    # Open PRs
gh pr list --state merged     # Merged PRs
gh pr list --author @me       # Your PRs

Add a review comment (from CLI)

gh pr review <pr-number> --comment --body "LGTM"
gh pr review <pr-number> --approve --body "Approved"
gh pr review <pr-number> --request-changes --body "Please fix X"

Merging a Pull Request

Merge with default strategy (repo setting)

gh pr merge <pr-number>

Merge strategies

Examples:

gh pr merge 42 --squash --delete-branch
gh pr merge 42 --merge
gh pr merge 42 --rebase

Common merge options

• •--delete-branch — Delete the branch after merge (local and remote when using squash/merge).
• •--auto — Enable auto-merge when checks pass (GitHub will merge automatically).
• •--admin — Merge even if branch is not up to date (use with care).

Merge without merging (close as not merged)

gh pr close <pr-number>

Workflow checklist

Before creating a PR:

• • Branch is up to date with base (e.g. git fetch origin && git rebase origin/main)
• • Commits are logical; consider squash if many small fixes
• • Title and description explain what and why

Before merging:

• • CI passes
• • Review approved (if required)
• • Choose correct strategy: squash for single-feature PRs, merge when preserving history

Quick reference