Creating a well-structured pull request (PR) is crucial for maintaining code quality and ensuring smooth collaboration in a project. A clear and concise PR description helps reviewers understand the changes made and the rationale behind them, facilitating a more efficient review process.

Ticket ID

Including a ticket ID in the PR title helps track the changes back to the original issue or feature request. It provides context and allows team members to quickly identify the purpose of the PR.

For example, there is a project named ERP. The ticket ID for a new feature request is ERP-34. The PR title should include this ticket ID.

PR Title

The PR title should be concise and descriptive, summarizing the main changes introduced in the PR. It should provide a clear indication of the purpose of the PR, making it easier for reviewers to understand the scope of the changes. It should have title case. It should also prepend the ticket ID to the title for better tracking.

Bad Examples

“Added a new feature to the project that helps with the user experience.”

“Fixed a bug in the code that was causing the application to crash.”

“Refactored the entire codebase to improve performance.”

Good Examples

“[ERP-34] Add User Experience Enhancement”

“[ERP-24] Fix Application Crash Bug”

“[ERP-90] Refactor Codebase for Performance”

Description

The PR description should provide a detailed explanation of the changes, including the motivation behind them and any relevant context. It should be clear, concise, and well-structured.

Bad Examples

“This PR adds a new feature to the project.”

Added a new feature that improves the user experience by providing better navigation.

“Fixed a bug.”

There was a bug in the code that caused the application to crash. This PR fixes that bug.

“Refactored the code.”

The codebase was refactored to improve performance. This involved changing a lot of files and methods.

Good examples

“[ERP-34] Enhance User Experience”

### Summary
This PR adds a new feature that improves the user experience by providing better navigation.

### Changes
* Added navigation buttons to the sidebar
* Improved layout and design of the main page
* Updated CSS styles for consistency

### Motivation
This enhancement aims to make the application more user-friendly and intuitive, addressing user feedback regarding navigation difficulties.

“[ERP-31] Fix Application Crash on Login”

### Summary
This PR fixes a bug that was causing the application to crash when users attempted to log in.

### Changes
* Added null checks to the login function
* Updated error handling to provide more informative messages

### Motivation
The bug was reported by several users and was a critical issue that needed immediate attention.

“[ERP-39] Refactor Codebase for Improved Performance”

### Summary
This PR refactors the codebase to improve overall performance.

### Changes
* Optimized database queries
* Reduced redundant code
* Implemented caching for frequently accessed data

### Motivation
The refactor aims to enhance the application's performance, making it faster and more efficient for users.

Summary

Pull request formats should have the following properties

  • Detailed description with a summary, changes, and motivation
  • Use bullet points for readability
  • Avoid redundancy and keep explanations to the point

Following these guidelines will help ensure that your pull requests are easy to review and understand, facilitating better collaboration and code quality.

Add .github/PULL_REQUEST_TEMPLATE.md to Your Repository

To enforce a consistent PR format across your project, you can create a .github/PULL_REQUEST_TEMPLATE.md file in your repository. This template will be automatically displayed when users create a new PR, guiding them to provide the necessary information in the correct format.

# Pull Request Template

## Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes # (issue)

## Type of Change

Please delete options that are not relevant.

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

- [ ] Test A
- [ ] Test B

**Test Configuration**:

- Firmware version:
- Hardware:
- Toolchain:
- SDK:

## Checklist:

- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules
- [ ] I have checked my code and corrected any misspellings

This template can be customized to suit your project’s specific requirements and guidelines. By using a PR template, you can ensure that all PRs follow a consistent format, making it easier for reviewers to understand the changes and provide feedback.