Pull Request Description Templates

Also Known As

TL;DR

Explanation

A good PR template includes: Summary (what does this change do?), Motivation (why is this change needed? links to issue), Type of change (bug fix, feature, breaking change, refactor), How to test (steps to reproduce the scenario being changed), Screenshots (for UI changes), Checklist (tests added, documentation updated, migrations run). Stored in .github/PULL_REQUEST_TEMPLATE.md — automatically pre-fills the PR description on GitHub. Multiple templates: .github/PULL_REQUEST_TEMPLATE/ directory with multiple files selectable via URL parameter.

Common Misconception

Why It Matters

Common Mistakes

• Overly long templates — developers leave all fields blank rather than fill in 20 sections.
• No testing instructions — how is the reviewer supposed to verify the change?
• Checklist items that are never checked — if nobody checks them, remove them.
• Same template for all PR types — a hotfix needs different information than a new feature.

Code Examples

# No PR template — PRs are descriptions like:
# Title: 'Fix bug'
# Description: 'Fixed the thing that was broken'
# How to test: (empty)
# Related issue: (empty)
# Reviewer: spends 20 minutes asking questions before starting review

# .github/PULL_REQUEST_TEMPLATE.md:
## Summary
Brief description of what this PR does.

## Motivation
Fixes # (issue number) | Implements # (issue number)

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Refactor

## How to Test
1. Checkout this branch
2. Run: `php artisan migrate`
3. Navigate to /checkout
4. Expected: ...

## Checklist
- [ ] Tests added/updated
- [ ] No new PHPStan errors (`composer stan`)
- [ ] Database migration is reversible

References

• ↗ https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests

Tags

Related Terms