Creating Github pull request templates

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

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

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

## 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

## 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

## Description 📋

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