Pull request template generator for GitHub repositories

How to use the pull request template generator

1. Tick the sections you want: Summary, Related issue, Type of change checklist, How it was tested, Screenshots, Breaking changes and Review checklist.
2. Watch the preview update as you tick and untick. Sections always appear in that order.
3. Copy or download pull_request_template.md.
4. Save it as .github/pull_request_template.md and commit it to the default branch.
5. Open a test pull request to see the template in the description box, then adjust the wording if needed.

What it does and when to use it

Reviewers spend less time asking basic questions when every pull request explains what changed, why, and how it was tested. A template puts those prompts in front of the author before they press Create. It helps most in shared repositories, open-source projects with outside contributors, and teams that want UI changes shown with screenshots.

Keep it short; a long form gets skipped. The CONTRIBUTING.md generator writes a guide whose pull request steps tell authors to fill in this template, and the issue template generator does the same job for bug reports. For linked issues to close themselves, the related issue section works with the “Closes #” keyword.

How it works

Each ticked box adds one Markdown block:

• Summary and How it was tested add a heading with an HTML comment prompt.
• Related issue adds Closes # for the author to complete.
• Type of change adds five task-list boxes: bug fix, new feature, breaking change, documentation, refactor or maintenance.
• Screenshots and Breaking changes add headings with a prompt to delete them when they do not apply.
• Review checklist adds five boxes about the contributing guide, style and lint, tests, documentation, and passing tests locally.

The first line is a comment reminding you where to save the file. GitHub’s own guide covers creating a pull request template.

Worked examples

The default template contains Summary, Related issue, Type of change, testing and Checklist. Its change type section:

## Type of change

- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that changes existing behaviour)
- [ ] Documentation
- [ ] Refactor or maintenance

A front-end library template. Untick Related issue, Type of change and Review checklist; tick Screenshots and Breaking changes. The result has four headings: Summary, How has this been tested?, Screenshots, and Breaking changes and migration, each with its comment prompt.

Limits and tips

• If you untick every box, the file contains only the save-location comment.
• The checklist wording is fixed. Edit the lines to match your project, for example “I added a changelog entry”.
• Templates are suggestions. Authors can delete everything, so pair them with automated checks for anything that truly matters.