IT Phrases Guide
English Phrases for Writing PR Description — IT Professional's Guide
English vocabulary and phrases for writing clear, professional pull request descriptions that help reviewers quickly understand your changes.
9 phrases across 2 situations · 3 phrases to avoid · 5 exercises · 10 FAQ items
Structuring the Description
- ## What this PR does [2–3 sentences explaining the change and why]The most important section — every PR needs this
"## What this PR does Adds rate limiting to the authentication endpoint to prevent brute-force attacks. Limits to 10 attempts per IP per 15 minutes."
- ## Why [Business or technical motivation]Context for the reviewer and future readers
"## Why We saw a spike in failed login attempts last week — this adds a basic defensive layer before the security audit."
- ## How to test 1. [Step] 2. [Step]Numbered test steps that a reviewer can follow
"## How to test 1. Run the dev server locally 2. Attempt 11 logins with a wrong password 3. Confirm the 429 response on the 11th attempt"
- Closes #[issue number]Links the PR to the issue it resolves
"Closes #412 — rate limiting feature request"
Flagging and Communicating
- Note for reviewers: [important context or caveat]Drawing attention to non-obvious decisions
"Note for reviewers: I chose Redis over an in-memory store so rate limits survive service restarts."
- This is a breaking change — [what callers need to update].Always flag breaking changes explicitly
"This is a breaking change — callers must now pass an Authorization header or receive 401."
- Out of scope for this PR: [list of related work]Setting boundaries to prevent scope discussions in review
"Out of scope for this PR: CAPTCHA integration and IP allowlisting — tracked in #420 and #421."
- Screenshot / recording attached below.For UI changes — visual evidence speeds up review
"Screenshot of the updated modal attached below — before/after comparison."
- Draft — not ready for review yet.Marking a PR as a work in progress
"Draft — not ready for review yet. Opening for early visibility on the approach."
Phrases to Avoid
These common phrasings undermine your professionalism. Here are better alternatives.
"Various fixes" is meaningless. A specific description helps reviewers, future git-blamers, and changelog generators.
"WIP" alone gives no context. A brief description of the work state helps teammates track progress.
Making reviewers discover your rationale through code reading wastes their time and risks rejection of a good approach.
Practice Exercises
Choose the most professional or correct phrase for each scenario.
Frequently Asked Questions
What does "closes #[number]" do in a PR?
"Closes #123" in a PR description (on GitHub/GitLab) automatically closes the linked issue when the PR is merged. It connects the work to the requirement.
What is a "breaking change"?
A breaking change is a modification that makes existing code incompatible with the new version — such as removing an API endpoint, renaming a parameter, or changing a data format.
What is a "draft PR"?
A draft PR is a work-in-progress pull request that signals it's not ready for formal review. GitHub and GitLab have a dedicated draft status that prevents accidental merges.
What does "LGTM" mean?
"Looks Good To Me" — a common code review approval phrase. Some teams require at least one LGTM before merging.
What is a "squash merge"?
A squash merge collapses all commits in a PR into a single commit on the target branch. It creates a cleaner git history but loses individual commit messages.
What is a "rebase"?
Rebasing replays your branch's commits on top of the latest main branch, creating a linear history. It's an alternative to merge commits, often preferred for cleaner logs.
What does "cherry-pick" mean?
Cherry-picking applies a specific commit from one branch onto another, without merging the entire branch. Useful for backporting hotfixes.
What is a "hotfix"?
A hotfix is an urgent patch deployed directly to fix a critical production issue, bypassing the normal sprint or release cycle.
What does "git blame" mean?
"git blame" shows who last modified each line of a file and in which commit. Used to trace the origin of a bug or understand the context of a line of code.
What is a "changeset" or "changelog"?
A changelog is a record of changes between software versions. A changeset is the group of changes in a single release. Good PR descriptions feed directly into changelogs.