Skip to main content

Create a pull request template

· 2 min read
Daniel Guo
Daniel Guo
Software Engineer

You can create a pull request template based on Creating a pull request template for your repository from Github:

  • you can put it in the repository's root directory: ./pull_request_template.md
  • you can put it in the repository's docs directory: ./docs/pull_request_template.md
  • you can put it in a hidden directory: ./.github/pull_request_template.md
  • you can put multiple pull request templates in a PULL_REQUEST_TEMPLATE subdirectory in the root director, docs directory, or .github hidden directory.

Benefits​

Pull request (PR) templates ensure consistency in PR descriptions, clarify expectations, improve code quality, and ultimately, streamline the review process. By providing a structured format, PR templates reduce back-and-forth communication and save time for both reviewers and contributors.

  • Consistency: PR templates standardize the information included in each PR, making it easier for reviewers to understand the changes and assess their impact.
  • Clarity:: They prompt contributors to provide essential details about their changes, including the problem being solved, the approach taken, and any testing steps. This reduces ambiguity and misunderstandings.
  • Efficiency: By providing a structured format, PR templates reduce the time spent on back-and-forth communication, allowing reviewers to focus on the actual code changes.
  • Quality Control: Templates can include checklists for testing, documentation updates, and other quality-related tasks, ensuring that contributors remember to address these aspects.
  • Improved Documentation: Detailed PR descriptions, guided by the template, serve as valuable documentation for the codebase, making it easier for future developers to understand the rationale behind changes.

Template​

Here is a pull request template that I shared within the team:

## Summary

_A brief description of changes and motivation behind them._

## Type of Change

- [ ] Bug fix (non-breaking change fixing an issue)
- [ ] New feature (non-breaking change adding functionality)
- [ ] Breaking change (fix or feature causing existing functionality to not work as expected)
- [ ] Documentation update
- [ ] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Configuration/infrastructure changes

## Changes Made

- _your changes_
- ...

## Checklist

- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Code is properly commented
- [ ] Tests added for new functionality
- [ ] Documentation updated (if needed)
- [ ] No merge conflicts

## Testing

- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing completed
- [ ] N/A (docs etc.)

## Reviewer Notes

_Any specific areas you'd like reviewers to focus on_

Reference​