Анатомия хорошего PR

Maintainer Linux kernel Линус Торвальдс публично отвергал PR без описания. Maintainer React отклоняет PR без тестов автоматически. Contributor в kubernetes/kubernetes получил 'LGTM' за 3 часа с хорошим PR; другой contributor ждал 3 недели с плохим. Хороший PR - это не формальность, это способ коммуникации с людьми которые добровольно тратят время на review чужого кода.

• **Kubernetes** - PR template требует: описание, release notes, затронутые areas, тесты; CI запускает 40+ проверок; без описания бот автоматически добавляет метку 'needs-description'
• **React** - все PR должны иметь тест; failing test в PR description как доказательство проблемы ('этот тест красный без фикса'); reviewer видит до/после одним кликом
• **VSCode** - PR > 1000 строк автоматически помечается как 'large'; team policy: разбить или объяснить почему нельзя; 90% PR < 200 строк что ускоряет review cycle до <24 часов

PR description: что и зачем

Maintainer проекта получает 50 PR в неделю. PR без описания - чёрный ящик: непонятно что сломано, зачем правка, как проверить. Хорошее описание PR это не бюрократия, это уважение к чужому времени и способ быстро смерджиться.

Минимальное описание PR: **What** (что изменено и почему), **How to test** (как воспроизвести и проверить), **Linked issue** (`Closes #123` или `Fixes #456` - автоматически закрывает issue при merge). Опционально: скриншоты до/после для UI изменений, migration notes для breaking changes.

Хорошее название PR - как хороший commit message: imperative, конкретное, без 'WIP' или 'fix stuff'. `fix: prevent crash in calculateAverage when input is empty` - maintainer понимает за 3 секунды что это и хочет ли он вообще эту правку.

Чек-лист перед открытием PR

Хороший PR - маленький, атомарный и самодостаточный. Правило: если ревьюеру нужно больше часа чтобы понять изменения - PR слишком большой. Google Engineering Practices: PR должен делать одно логическое изменение. 200 строк - нормально, 2000 строк - разбить.

Чек-лист перед открытием: **Scope** (одна задача, не 'заодно исправил...'). **Tests** (написал тест на изменение). **CI green** (все проверки прошли локально). **Rebase on main** (нет merge conflicts). **Self-review** (прочитал diff сам прежде чем отправить). **Description** (что/почему/как тестировать).

Self-review - самый важный шаг. Открыть PR в GitHub UI (не в IDE), прочитать каждую строку как reviewer. Часто обнаруживается: забытый debug print, ненужный whitespace change, TODO без issue, неверный комментарий. 10 минут self-review экономят 30 минут ревьюера.

Ключевые идеи

• **Описание PR**: что изменено, почему, как тестировать; 'Closes #N' для автозакрытия issue; скриншоты для UI
• **Small PR**: одна логическая задача; 200 строк норма; 1000+ строк -> разбить на несколько PR
• **Self-review**: прочитать diff в GitHub UI перед отправкой; экономит время ревьюера и улучшает качество
• **CI green + tests**: не отправлять PR с красными проверками; тест на изменённую логику обязателен

Связанные темы

Хороший PR строится на основе хорошей git практики:

• Commit messages — Хорошие commit messages в PR - основа читаемой истории проекта
• Code Review как contributor — Понимание review процесса помогает написать PR который легко проверить

Вопросы для размышления

• У тебя большой PR (800 строк): рефакторинг + новая фича + баг-фикс. Как разбить на несколько маленьких PR и в каком порядке их открывать чтобы не создать merge conflicts?
• Maintainer проекта отвечает на PR раз в неделю. Как написать описание и задать вопросы чтобы получить максимально полезную обратную связь за один цикл (не пинг-понг на 2 недели)?
• CI упал на твоём PR из-за flaky test который не связан с твоими изменениями. Как задокументировать это в PR и что делать дальше?

Связанные уроки

• se-02