Pull request (у GitLab - merge request) - це пропозиція влити зміни з однієї гілки в іншу. Навколо неї відбувається все обговорення: рев'ю коду, коментарі до рядків, результати CI, затвердження. Сам Git про pull request нічого не знає - це функція платформи (GitHub, GitLab, Bitbucket).
Навіщо потрібен опис: рев'юер бачить диф, але не бачить, навіщо зміна зроблена, які варіанти відкинуто і як її перевірити. Добрий опис економить кілька раундів запитань.
Шаблон опису:
## Що і навіщо
Додає експорт вакансій у CSV для адмінки. Менеджери зараз копіюють
таблицю вручну.
Closes #412
## Як зроблено
- `VacancyExport` формує файл потоково, щоб не тримати 50k рядків у пам'яті
- експорт іде в черзі, посилання приходить листом
## Як перевірити
1. Адмінка → Вакансії → «Експорт»
2. Дочекатися листа, відкрити файл
## На що звернути увагу
Не впевнений щодо формату дат - зараз ISO 8601.
Що робить опис добрим:
- проблема, а не перелік файлів - «що змінилося» видно в дифі, а «чому» - ні;
- посилання на задачу (
Closes #412) - контекст і автоматичне закриття задачі; - інструкція з перевірки - рев'юер може відтворити поведінку;
- скріншоти чи відео для змін інтерфейсу;
- ризики й відкриті питання - куди дивитися уважніше;
- заголовок як у доброго коміту - коротко про суть: «Експорт вакансій у CSV», а не «fix» чи «updates».
Шаблон для всієї команди - файл .github/pull_request_template.md: GitHub підставляє його в кожен новий pull request, і структура опису стає однаковою.
