Pull Requests and Code Review
A pull request (PR) — called a merge request on GitLab — is not a Git primitive at all; it is a feature of hosting platforms like GitHub, GitLab, and Bitbucket that wraps a Git operation (merging one branch into another) in a collaborative review workflow. Under the hood a PR is just a comparison between two refs, typically a feature branch and a target branch such as main. What makes it powerful is everything the platform layers on top: a diff view, threaded comments on specific lines, required status checks, approval rules, and a merge button that only becomes active once the team's policies are satisfied. Understanding this separation matters because it explains why you can git merge locally without ever touching a PR, and why a PR can sit open for days accumulating commits and conversation before the underlying merge actually happens.
Cricket analogy: A PR is like the third-umpire review system layered on top of the raw game of cricket — the umpire's on-field decision (the merge) is the actual act, but the review workflow with replays, snickometers, and a decision review request is a platform feature, not part of cricket's core rules.
Opening a strong pull request
A good PR starts before the first commit — you push a branch, open the PR early (often as a draft), and let the description do real work. The description should state what changed, why, how it was tested, and any risk or rollout considerations; screenshots and before/after output matter for UI or CLI-facing changes. Small, focused PRs are dramatically easier to review than sprawling ones: a 100-line diff that does one thing gets thorough scrutiny, while a 2,000-line diff touching five subsystems gets skimmed. Many teams enforce this culturally by asking contributors to split unrelated changes (a refactor plus a feature) into separate PRs.
Cricket analogy: This is like a batter announcing their game plan to the coach before facing a single ball — a small, focused innings targeting one bowler's weakness gets careful tactical review, while trying to overhaul the whole batting order in one session gets only a glance.
# Typical PR lifecycle from the command line
git checkout -b feature/rate-limit-middleware
# ... make changes, commit ...
git push -u origin feature/rate-limit-middleware
# Using the GitHub CLI to open a PR without leaving the terminal
gh pr create \
--base main \
--title "Add token-bucket rate limiting middleware" \
--body "Introduces per-IP rate limiting using a token bucket.\n\nTested with k6 load script in scripts/load-test.js."
# Reviewer fetches the PR branch locally to test it
gh pr checkout 482
npm test
# After approval, merge and clean up
gh pr merge 482 --squash --delete-branchReviewing code effectively
Reviewing is a skill distinct from writing code. Effective reviewers read for correctness first (does this do what it claims, are edge cases handled, are tests meaningful), then for maintainability (naming, structure, whether the change fits existing patterns), and only last for style — and even then, style nits are best automated away with linters and formatters so humans don't spend review time on semicolons. Comments should be specific and actionable: 'this will throw if items is empty, add a guard' is useful; 'this looks off' is not. Distinguishing blocking comments from optional suggestions (many teams prefix nits with 'nit:' or use suggestion comments) keeps review from stalling on non-essential feedback.
Cricket analogy: This is like a bowling coach reviewing a delivery: first checking if it actually got the batter out (correctness), then whether the bowler's action holds up over a spell (maintainability), and only last commenting on style — a coach doesn't nitpick follow-through when the yorker just took the stumps.
Merge strategies
Most platforms offer three ways to land a PR: a regular merge commit (preserves every commit and creates a merge commit recording the join), a squash merge (collapses all commits on the branch into a single commit on the target branch, keeping history linear), and a rebase merge (replays the branch's commits individually onto the target with no merge commit at all). Squash merging is popular for feature branches with messy work-in-progress commits because the target branch ends up with one clean, reviewable commit per PR; teams that value granular history or use conventional commits per logical change often prefer rebase merges instead.
Cricket analogy: This is like three ways a team can close out an innings summary: keep every over's ball-by-ball log intact (merge commit), condense the whole innings into one final scorecard line (squash), or replay each over's runs individually onto the match total with no combined summary entry (rebase).
GitHub's 'suggested change' comments let a reviewer propose an exact code replacement inline; the author can accept it with one click, which creates a commit on their behalf — a fast way to fix typos or small issues without a review round-trip.
Force-pushing to a branch after review has started (e.g. after an interactive rebase) rewrites commit SHAs and can silently discard a reviewer's in-progress line comments or make it hard to see what changed since their last pass. Prefer adding fixup commits during active review and squashing only once, right before merge.
- A pull request is a platform feature, not a Git command — it wraps a comparison between two branches with discussion and approval workflows.
- Small, focused PRs with clear descriptions get faster, higher-quality reviews than large multi-purpose ones.
- Effective review prioritizes correctness and maintainability over style, which should be automated instead.
- Squash merges produce clean linear history at the cost of per-commit granularity; merge commits preserve full history.
- Force-pushing mid-review can erase reviewer context on a branch — coordinate before rewriting pushed history.
- Draft PRs let contributors get early feedback or run CI before formally requesting review.
Practice what you learned
1. Which statement about pull requests is accurate?
2. What is the main trade-off of squash merging a feature branch?
3. Why is it risky to force-push a branch in the middle of an active code review?
4. What is the primary purpose of a draft pull request?
5. In an effective code review, which type of feedback should generally take priority over style nitpicks?
Was this page helpful?
You May Also Like
Feature Branch Workflow
A widely used team workflow where every change lives on its own short-lived branch off main, gets reviewed via pull request, and is merged once approved and tested.
Commit Message Conventions
Why disciplined, structured commit messages make history searchable and automatable, and how conventions like Conventional Commits standardize their format.
Branch Protection and CI Checks
Explore how branch protection rules and required CI status checks stop broken or unreviewed code from reaching important branches like main.
GitHub Issues and Project Boards
Learn how GitHub Issues track bugs and tasks, and how Project boards organize that work visually so teams can plan, prioritize, and ship together.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics