Creating Github pull request templates

A guide to creating default PR templates for a repository on Github.

blogpost logo image
Github

Getting started

๐Ÿ“ Getting started

To create a template for your repository all you need to do is create a file named PULL_REQUEST_TEMPLATE.md in either:

  • a .github folder - my preferred option here
  • the root of your project
  • a docs folder

Once this is pushed to the default branch for the project Github will start using it as the default template for new pull requests. It’s as simple as that! โœจ

The benefits

๐Ÿ“ The benefits

There are many benefits to setting up a default pull request template. The biggest is consistency, all of the developers working on that project will fill out a consistently structured pull request making them easier to read and review.

Another great benefit of setting up a template is that it could prompt the submitter for extra detail. For example this may be screenshots of their changes or requiring them to fill out a checklist of pre-submission tasks.

Gone will be the days of opening up a pull request to see those dreaded words “No description” - That’s just not helpful to anyone. Now you and your collaborators can finally open a PR and quickly understand what the change is and why it’s been created.

My templates

๐Ÿ“ My templates

I’ve composed a few templates below to help you get started, these can all of course be customised and chopped apart to suit your needs!

Internal team collaboration project

๐Ÿ“ Internal team collaboration project
## Description ๐Ÿ“‹

Please include a summary of the changes made in this PR.

## Type of change ๐Ÿค”

Please tick any that are relevant to this PR and remove any that aren't.

- [ ] Bugfix ๐Ÿ›
- [ ] Feature ๐Ÿฅณ
- [ ] Refactoring ๐Ÿค“
- [ ] CI ๐Ÿค–
- [ ] Documentation ๐Ÿ“’
- [ ] Tests ๐Ÿงช
- [ ] Other (please detail in description) โ“

## Screenshots ๐Ÿ“ท

If possible provide screenshots of your visual changes to make it easier for reviewers.

Open source project

๐Ÿ“ Open source project
## Description ๐Ÿ“‹

Please include a summary of the changes made in this PR and provide any context necessary for the change.
Fixes # (issues)

## Type of change ๐Ÿค”

Please tick any that are relevant to this PR and remove any that aren't.

- [ ] Bugfix (non breaking change which resolve an issue)
- [ ] Feature (non breaking change which adds functionality)
- [ ] Breaking Change (a change which would cause existing functionality to not work as expected)
- [ ] Documentation (a change to documentation)

## Submission checklist โœ…

- [ ] I have performed a self review of my changes
- [ ] I have updated the documentation where relevant
- [ ] My changes are well written and all ci is passing

Minimal

๐Ÿ“ Minimal
## Description ๐Ÿ“‹

Please include a summary of the changes made in this PR and provide any context necessary for the change.