Pull Request Template
A Pull Request template is a standardized document that helps developers submit high-quality PRs. By providing a consistent format, the template allows team members to understand and review code changes more efficiently. The following is a guide to creating and using GitCode Pull Request templates.
Creating a Pull Request Template
-
Choose the template location:
You can place the PR template in the project's
.gitcode/folder (create it if it does not exist), or place it indocs/or.gitcode/PULL_REQUEST_TEMPLATE/directory, and create aPULL_REQUEST_TEMPLATE.mdfile within it. You can create multiple template files in the.gitcode/PULL_REQUEST_TEMPLATE/folder, and GitCode will display the created templates when a PR is created for this project for use.
提示The template configuration must be placed in the default branch of the repository. If you create the template in another branch, the configuration will not take effect, and the related features cannot be used by collaborative users.
-
Write the template content:
Write the content of the template in the
PULL_REQUEST_TEMPLATE.mdfile. You can include some basic header information, problem description, change type, test instructions, and any additional notes or explanations. Make sure to prompt contributors to provide all the information you think is helpful for the review. You can configure front-matter information in the new.mdfile, including the title of the PR template, the person assigned to merge, and the specified label. Also add the body content in the new.mdfile, which will be pre-filled into the description when a user creates a new PR.Example Template:
---
title: "【PR template】:"
labels: ["fix","bug"]
assignees: 'username'
---
# Pull Request Template
----
## Description
Provide a high-level overview of this Pull Request.
## Type
- [ ] Bug Fix
- [ ] New Feature
- [ ] Code Style Update (Formatting, Local Variables)
- [ ] Refactor (i.e., code changes that are neither new features nor bug fixes)
- [ ] Changes to the build process or auxiliary tools
- [ ] Documentation updates
## How to Test
Describe the steps to test this change, including which files need to be modified.
## Checklist:
- [ ] My code follows the style of this project
- [ ] I have tested my code myself
- [ ] I have updated the corresponding documentation
- [ ] I have updated the relevant change log as needed
- [ ] I have correctly used the type tag in the title (e.g., `feat:`, `fix:`)
## Additional Information
Add any additional notes related to this Pull Request here.
If you need to use a separator within the template, do not use three "-" symbols "----", to avoid conflicts with the separator symbol in the template rules. It is recommended to use four "-" symbols "----".

-
Using the Template:
Once you have created the template, GitCode will automatically fill your template content into the PR description box when a contributor creates a Pull Request. Contributors should fill in all relevant information according to the template prompts.

Introduction to Front-matter
Currently, we support the following types of markdown front-matter configurations:
| Field | Description | Notes |
|---|---|---|
| title | Pre-set title for PR | Use double quotes if containing Chinese |
| labels | Labels for PR, supports multiple | Multiple labels need to use brackets, and when there are non-existent labels, they will not be displayed when creating a PR |
| assignees | Default assignee for PR | Username of the person assigned to merge |
Notes
- Clear and concise: Ensure your template is clear and concise so contributors can easily understand and follow it.
- Flexibility: Encourage contributors to follow the template, but also allow a certain degree of flexibility. Not every part needs to be filled by every contributor.
- Update and maintenance: As the project evolves, regularly update your template to ensure it remains relevant and continues to help achieve the project's goals.
By providing clear and well-organized Pull Request templates, you can improve the quality of your project, speed up the PR review process, and help contributors participate more effectively in the project.