linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
Intro
Lessons
Footer
linuxlab-TutorialsPricingAboutPrivacy & cookies
Copyright © 2026 LinuxLab. All rights reserved.
linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
  • Introduction
  • Chapters
  • How it works
  • Lessons
  • Knowledge base
  • Interview prep
home/git/kb/Collaboration/pr-template

kb/collab ── Collaboration ── beginner

Pull Request template

The file `.github/PULL_REQUEST_TEMPLATE.md` is pre-filled into the description field of every new PR in the repo. It standardizes the structure: what/why/how to test/checklist. Saves reviewer time and reduces re-review because the author self-checks before submitting.

view as markdownaka: pull-request-template, pr-templates

A Pull Request template is a Markdown file that GitHub automatically inserts into the description of a new PR. The goal is for every PR to have a structured description rather than a single line like "fix bug."

Where to put it

GitHub looks in three places:

  • .github/PULL_REQUEST_TEMPLATE.md (the standard location)
  • PULL_REQUEST_TEMPLATE.md in the root
  • docs/PULL_REQUEST_TEMPLATE.md

For multiple templates, use a directory:

.github/PULL_REQUEST_TEMPLATE/
  feature.md
  bugfix.md
  docs.md

Select a specific template via the URL parameter ?template=feature.md when creating a PR.

A minimal useful template

markdown
## What
<!-- One or two lines describing what changes. -->
## Why
<!-- What problem this solves, or a link to the issue.
     Example: Fixes #142 -->
## How to test
1. Step 1
2. Step 2
3. Expected result
## Checklist
- [ ] Tests added or updated
- [ ] Documentation updated (if needed)
- [ ] Reviewed my own diff and removed unintentional changes

The checklist is not decorative. When the author ticks the boxes, they re-read the PR and often catch something they missed.

Linking to an issue

Certain keywords in the PR description automatically close a related issue after merge:

Fixes #142
Closes #143
Resolves #144

GitHub recognizes these forms automatically. On merge, the issue is closed and a reference is added.

Combined with CONTRIBUTING.md

The PR template is the minimum every PR must fill in. contributing-md provides the context: which tests are required, which code style to follow, how to ping maintainers, and any DCO sign-off requirements. The template links to CONTRIBUTING rather than repeating it.

What NOT to put in the template

  • Long policy statements. "Remember to be kind" belongs in CODE_OF_CONDUCT.md.
  • Full style documentation. Too much text leads authors to delete the template entirely, leaving the description empty.
  • Yes/no questions instead of [ ] checkboxes. Checkboxes are clickable in the UI; plain text is not.

Issue templates

By the same pattern: .github/ISSUE_TEMPLATE/bug.md plus additional templates for other issue types. GitHub displays them as choices when someone creates an issue. Useful for projects with a high volume of bugs and feature requests.

§ команды

bash
ls .github/

Check whether templates exist in the repo

§ см. также

  • pull-requestPull Request (PR)A request to merge a branch into the main branch after passing review and CI. On GitHub/GitLab/Bitbucket it is the standard mechanism for collaborative work. Technically it is not a Git command but a hosting feature built on top of branches and commits.
  • contributing-mdCONTRIBUTING.mdA file in the repository root (or in `.github/`) that sets the rules for contributors: how to set up the environment, how to format commits, how to submit a PR. The clearer the CONTRIBUTING file, the fewer "how do I run this?" questions land in Issues.
  • code-reviewCode reviewReading and discussing another developer's code before merge. The primary goal is sharing context, not finding bugs (bugs are a side effect). A good review improves the code and spreads knowledge of the system across the team.
Footer
linuxlab-
Copyright © 2026 LinuxLab. All rights reserved.
Tutorials
Pricing
About
Privacy & cookies