Master the Pull Request: A Developer's Guide to Git CLI and GitHub

gitgithubpull-requestgit-clibranchingcommitcode-review

A pull request, usually shortened to PR, is the standard way to propose changes to a shared codebase. It lets teammates review the work, discuss implementation details, request changes, and merge the branch into the main project when it is ready.

This guide covers the basic professional workflow: create a branch locally with Git, commit and push the work, open a PR on GitHub, respond to review comments, and clean up after merge.

Step 1: Create a Working Branch

Avoid working directly on main or master. A dedicated branch keeps unfinished work isolated and makes review easier.

Start by moving to the main branch and syncing it with the remote repository.

git checkout main
git pull origin main

Create and switch to a new feature branch.

git checkout -b feature/add-dark-mode

Use a short, descriptive, hyphenated branch name. Common prefixes include:

feature/add-dark-mode
fix/header-overflow
docs/update-readme
refactor/navigation-state

The -b flag tells Git to create the branch and switch to it in one command.

Step 2: Commit and Push Your Work

After editing the code, check which files changed.

git status

Stage the changes you want to include.

git add .

For more precise commits, stage specific files instead of everything.

git add styles.css
git add src/components/ThemeToggle.tsx

Commit the staged changes with a clear message.

git commit -m "Add dark mode toggle and theme variables"

Push the branch to GitHub.

git push origin feature/add-dark-mode

For the first push, you can also set the upstream branch.

git push -u origin feature/add-dark-mode

After setting upstream, future pushes from the same branch can usually be shortened to:

git push

Step 3: Open the Pull Request

Once the branch exists on GitHub, open a pull request.

Option A: GitHub Web Interface

  1. Open the repository on GitHub.
  2. If GitHub shows a banner for the recently pushed branch, click Compare & pull request.
  3. If there is no banner, open the Pull requests tab and click New pull request.
  4. Select the base branch, usually main, and the compare branch, such as feature/add-dark-mode.
  5. Write a clear title and description.
  6. Click Create pull request.

A useful PR description usually explains:

  • What changed
  • Why the change was needed
  • How it was tested
  • Screenshots or recordings for UI changes
  • Related issues or tickets

Option B: GitHub CLI

If the GitHub CLI is installed and authenticated, create the PR from the terminal.

gh pr create --title "Add dark mode feature" --body "This PR introduces a dark mode toggle to the main navigation navbar."

If you omit the --title and --body flags, gh can prompt you interactively.

gh pr create

Checking PR Status from the Terminal

When you want to inspect PR state from a CLI, the most convenient approach is usually the official CLI for the hosting platform. For GitHub, use gh; for GitLab, use glab. GitLab calls PRs merge requests, so its commands use mr.

GitHub CLI: gh pr list

If GitHub CLI is installed and authenticated with gh auth login, use gh pr list to inspect pull requests in the current repository.

By default, gh pr list shows open PRs.

gh pr list

# Or explicitly:
gh pr list --state open

To list PRs that were closed without being merged:

gh pr list --state closed

To list merged PRs:

gh pr list --state merged

To list every state:

gh pr list --state all

Useful filters:

# PRs authored by you
gh pr list --author "@me"

# Increase the default result limit
gh pr list --limit 50

# Query a different repository
gh pr list -R owner/repository-name

For more options, check the official gh pr list manual.

GitLab CLI: glab mr list

In GitLab, the equivalent object is a merge request. glab mr list defaults to open merge requests.

glab mr list

Use these flags for other states:

# Closed merge requests
glab mr list --closed

# Merged merge requests
glab mr list --merged

# All merge requests
glab mr list --all

If you often switch repositories, -R lets you choose another repository.

glab mr list -R group/project

For more options, check the official glab mr list docs.

This keeps state checks close to the Git workflow: use git status for local changes, gh pr list or glab mr list for review objects, and the web UI only when you need deeper discussion or visual inspection.

Step 4: Respond to Review and Merge

After the PR is open, reviewers can leave comments, ask questions, approve the change, or request updates.

If reviewers request changes, keep working on the same branch. You do not need to create a new PR.

# Make the requested edits first
git status
git add .
git commit -m "Address PR review feedback"
git push

GitHub automatically updates the open PR with the new commits.

When the PR is approved and checks pass, merge it through GitHub. Depending on the repository settings, the merge method may be:

  • Merge commit
  • Squash and merge
  • Rebase and merge

Follow the repository’s preferred convention.

Step 5: Clean Up After Merge

After the PR is merged, delete the local branch.

git checkout main
git pull origin main
git branch -d feature/add-dark-mode

If the remote branch is no longer needed, delete it as well.

git push origin --delete feature/add-dark-mode

GitHub often offers a Delete branch button after a PR is merged.

Full Workflow Summary

git checkout main
git pull origin main
git checkout -b feature/add-dark-mode

# Edit files

git status
git add .
git commit -m "Add dark mode toggle and theme variables"
git push -u origin feature/add-dark-mode

gh pr create

After review:

# Apply requested changes
git add .
git commit -m "Address PR review feedback"
git push

After merge:

git checkout main
git pull origin main
git branch -d feature/add-dark-mode

Key Takeaways

  • Do not work directly on main for feature or bugfix work.
  • Keep branches focused and clearly named.
  • Commit related changes together with readable messages.
  • Push the branch to GitHub and open a PR for review.
  • Address review feedback on the same branch.
  • Merge only after approval and passing checks.
  • Delete old branches after the work is merged.
Related