Pull Request Template

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

• GitHub pull request template