Pull requests and code review

CLI examples labeled Bash work in Git Bash on Windows 10 and Windows 11, or Bash on Linux, with Git installed. Bash variable assignments such as DEFAULT_BRANCH=main are shell syntax; use Git Bash for these examples rather than pasting them into PowerShell or Command Prompt.

A pull request (PR) is a proposal to bring changes from one branch into another. GitLab calls the equivalent workflow a merge request (MR). A review compares the diff and its intended behavior. It should confirm correctness, scope, tests, error handling, security concerns and whether the change can be maintained by someone else.

Create a review request

GitHub Desktop

1. Commit and publish your feature branch.
2. Choose Preview Pull Request or Create Pull Request if available.
3. Confirm the base is main and the compare branch is your feature branch.
4. Desktop opens GitHub in your browser to finish the description, labels, reviewers and draft status.
5. For GitLab-hosted work, create a merge request through GitLab’s website instead.

Git CLI

git status --short --branch
git fetch origin
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD
git push -u origin feature/42-inventory
# Optional when GitHub CLI is installed and authenticated:
gh pr create --base main --head feature/42-inventory --draft

On GitLab, use the merge-request web interface or the separately installed glab tool. git itself does not create GitHub PR records.

Write a useful description

Explain what changed, why it was necessary, how you tested it and what could go wrong. Link the issue and add reproduction steps for bug fixes. For UI work, include before/after screenshots when useful. For migrations, document deployment order and rollback conditions. Don’t paste credentials or internal-only information into public requests.

Review, checks and merge strategy

See Merge commit, squash or rebase? for before/after history diagrams, pros and cons, and why a local merge serves a different purpose from a PR/MR.

A reviewer should check important paths, edge cases and whether the change matches its stated intent. CI can catch formatting, compilation and automated regressions; it cannot replace code review or manual testing. Use required checks and protected branches as enforcement rather than relying only on team habits.

Merge commit preserves branch integration history. Squash merge reduces a small branch to one commit. Rebase merge rewrites commit placement into a linear sequence. Pick a policy deliberately; do not rewrite others’ public work just to achieve a pretty graph. After merging, confirm the intended issue was updated and check which commit reached production.

Related: branch protection, conflicts and GitHub’s Desktop PR guide.

Branch naming: main is an example. Use master or your repository’s actual default branch where applicable. See Git terminology.