PR Title Conventions
Conventional Commits format, ideal length, WIP/Draft, breaking changes, and linting
PR title essentials
- Format: type: description (#issue) — Conventional Commits: feat, fix, refactor, docs, test, chore, perf
- Length: 50–72 characters — readable in PR lists, git log, and Slack without truncation
- WIP / Draft: "WIP:" prefix or GitHub Draft — signals not ready for merge
- Breaking changes: feat! or fix! — exclamation mark + BREAKING CHANGE: in description footer
- Enforce with automated linting (semantic-pull-request, commitlint) — don't rely on manual reminders
Question 0 of 5
Which PR title follows Conventional Commits format and is written most clearly?
type: description (issue reference) — Conventional Commits format. PR title formula:
- Type prefix: "fix:" — tells reviewers and changelog tools the nature of the change
- Imperative present-tense description: "resolve session timeout during large file uploads" — what the PR does
- Issue reference: "(#892)" — links to the issue in the PR list view
- feat: new feature
- fix: bug fix
- refactor: code restructure, no behaviour change
- docs: documentation only
- test: test additions
- chore: dependency update, config change
- perf: performance improvement
What is the ideal length for a PR title?
50–72 characters — readable in PR lists and git log without truncation. PR title length context:
- GitHub PR list shows ~72 characters before truncating on desktop
- GitHub mobile shows fewer — aim for the key info in the first 50 characters
- Git log in a terminal shows ~72 characters
- Slack PR notification shows the first ~60 characters
A PR title reads: "WIP: refactor auth module". What does "WIP" signal?
WIP = not ready for merge — early feedback or work-in-progress share. Draft PR vs. WIP prefix:
- GitHub Draft PRs: the modern standard — GitHub shows a "Draft" badge and prevents merging; reviewers know not to start a full review
- WIP: prefix: older convention from before GitHub Draft — still used on non-GitHub platforms
- WIP: in title: signals "I'm sharing this early for direction feedback" or "I'm not done but pushing for visibility"
Which PR title correctly indicates a breaking change?
feat! (or fix!): — the exclamation mark signals a breaking change in Conventional Commits. Breaking change notation:
- In title:
feat!: remove support for legacy OAuth1 authentication - In PR description footer:
BREAKING CHANGE: OAuth1 endpoints /auth/v1/token and /auth/v1/authorize are removed. Migrate to OAuth2 endpoints documented in the migration guide.
- The
!in the title flags it immediately in the PR list and git log - The
BREAKING CHANGE:footer in the description gives reviewers the migration path - Automated changelog tools (semantic-release, conventional-changelog) use both to generate major version bumps
A team has PRs with titles like: "stuff", "fixes", "update", "wip", "changes". What should they implement?
Automated PR title linting — enforces format before merge. PR title linting tools:
- semantic-pull-request: GitHub Action that checks the PR title matches Conventional Commits
- commitlint: can be configured as a CI check on PR titles
- danger.js: flexible PR automation that can enforce title patterns
- No type prefix (rejects "stuff", "update")
- Too short (rejects "fixes")
- Not starting with a lowercase type