Pull Request template - markdown-файл, который GitHub автоматически подставляет в описание нового PR. Цель - чтобы каждый PR имел структурированное описание, а не однострочное «fix bug».
Где лежит
Один из трёх путей, GitHub найдёт:
.github/PULL_REQUEST_TEMPLATE.md(стандарт)PULL_REQUEST_TEMPLATE.mdв корнеdocs/PULL_REQUEST_TEMPLATE.md
Для нескольких шаблонов - директория:
.github/PULL_REQUEST_TEMPLATE/
feature.md
bugfix.md
docs.md
Выбор конкретного - через URL-параметр ?template=feature.md при
создании PR.
Минимальный полезный шаблон
## What
<!-- Что меняется в одну-две строки. -->
## Why
<!-- Какую проблему решает или ссылка на issue.
Например: Fixes #142 -->
## How to test
1. Шаг 1
2. Шаг 2
3. Ожидание
## Checklist
- [ ] Тесты добавлены или обновлены
- [ ] Документация обновлена (если нужно)
- [ ] Сам прошёл по diff и нет лишних изменений
Чек-лист не для красоты. Когда автор отмечает галки, он перечитывает свой PR - и часто находит то, что забыл.
Линковка с issue
Ключевые слова в описании PR закрывают связанный issue после merge'а:
Fixes #142
Closes #143
Resolves #144
GitHub распознаёт эти формы автоматически. При merge'е issue закрывается и проставляется ссылка.
Сочетание с CONTRIBUTING.md
Шаблон PR - минимум, который PR должен заполнить. contributing-md - контекст: какие тесты обязательны, какой стиль кода, как пинговать maintainer'ов, какой DCO sign-off. Шаблон ссылается на CONTRIBUTING, не повторяет его.
Что НЕ класть в шаблон
- Длинные политические заявления. «Не забывайте быть
вежливыми» уместнее в
CODE_OF_CONDUCT.md. - Полную документацию по стилю. Слишком много текста авторы стирают целиком, и шаблон становится пустым.
- Yes/no вопросы вместо
[ ]галок. Чек-боксы автоматически кликабельны в UI; обычный текст нет.
Issue templates тоже бывают
По симметрии: .github/ISSUE_TEMPLATE/bug.md плюс ещё несколько
шаблонов для разных типов issues. GitHub показывает их в виде
выбора при создании issue. Удобно для проектов с большим
потоком багов и feature requests.