Первый pull request на новой работе читают не как вклад в продукт, а как образец вашего стиля. Ревьюер ещё не знает, аккуратный вы человек или тот, кто приносит 800 строк «заодно». Один маленький, чистый diff с понятным описанием сильнее большой фичи, которую потом неделю чинят.

Ниже — как выбрать задачу, пройти пайплайн, оформить описание и спокойно закрыть ревью. Без героизма и без «я пока учусь, извините». Цель первого PR — показать, что вы умеете доводить кусок до конца в правилах этой команды.

Коротко:

  • Берите маленькую задачу с понятным критерием готовности: баг, тест, документация, мелкая правка.
  • Сначала скопируйте стиль недавних смёрженных PR, а не «как принято в индустрии».
  • Один PR — одно изменение. Смешанный diff ревьюят хуже и дольше.
  • Описание отвечает на три вопроса: что, зачем, как проверить.
  • Комментарии ревью — про код, не про вас. Спрашивайте, не спорьте из принципа.

Зачем первый PR важнее размера задачи

Команда смотрит не на объём. Смотрят, умеете ли вы довести изменение до продакшена в их процессе: ветка, тесты, описание, реакция на замечания, отсутствие сюрпризов. Если первый вклад — огромный рефакторинг «я сразу улучшил архитектуру», вас запомнят как человека, которого нужно тормозить. Если первый вклад — 20 строк и зелёный пайплайн, вас запомнят как человека, с которым можно работать.

Это особенно заметно на удалёнке. В офисе новичка видят. На удалёнке вас видно по артефактам: сообщения в чате, тикеты, PR. Первый мёрж — самый дешёвый способ показать, что вы уже внутри процесса. Как встроиться в первую неделю в целом — отдельно в материале про первую неделю разработчика.

Какую задачу брать первой

Идеальный первый PR закрывает четыре условия:

  1. Результат видно за один-два дня, не за две недели.
  2. Критерий готовности ясен без продуктового спора.
  3. Затронутый код можно прочитать, не поднимая полсистемы.
  4. Есть к кому сходить с одним конкретным вопросом, если застряли.

Подходят: опечатка в пользовательском тексте, правка README после того, как вы сами споткнулись об инструкцию, недостающий тест на уже починенный баг, мелкий UI-баг с понятным воспроизведением, добавление лога в уже известное место. Не подходят: «переписать модуль», «навести порядок в зависимостях», «оптимизировать всё медленное», задача без описания и без шагов воспроизведения.

Если менеджер даёт крупную фичу в первый день, не геройствуйте молча. Спросите, можно ли вырезать из неё первый кусок: контракт, тест, кусок API, правку документации. Крупное изменение всё равно разобьют на ревью — лучше разбить сами. Как вообще читать незнакомый репозиторий, чтобы выбрать этот кусок, — в гайде как разобраться в чужой кодовой базе.

Подготовка до кнопки Create

До оформления PR пройдите локальный конвейер так, как его проходит команда, а не «у меня на машине работает».

  • Обновите основную ветку и перебазируйтесь или смёржьте её в свою, как принято здесь. Не приносите конфликт «разберётесь на ревью».
  • Прогоните линтер и тесты той командой, что в CI. Если CI гоняет подмножество — гоняйте то же подмножество плюс то, что вы трогали.
  • Посмотрите diff целиком глазами. Уберите отладочные принты, закомментированный код, случайные переформатирования чужих файлов, личные заметки.
  • Проверьте имена: ветка, коммиты, файлы. Если в проекте принят префикс тикета — поставьте его. Если squashing на мёрже — не устраивайте роман из десяти «fix»-коммитов, если вас об этом не просили.

Если тесты локально красные ещё до ваших правок — это отдельный разговор в чате, не часть вашего PR. Зафиксируйте: «на main уже падает X, моё изменение это не трогает». Иначе ревьюер решит, что сломали вы.

Как оформить описание

Заголовок — одно предложение в повелительном или изъяснительном наклонении, как в соседних PR. Не «правки», не «WIP пожалуйста посмотрите». Описание держит четыре блока. Их можно уложить в короткий шаблон.

Что изменилось: одной фразой, без истории жизни.

Зачем: баг / дырка в доке / пробел в тесте. Ссылка на тикет, если тикет есть.

Как проверить: шаги, команды, что считать успехом. Скрин или лог — только если без них не воспроизвести.

Риски и что не вошло: миграции, флаги, места, которые вы сознательно не трогали.

Если в репозитории уже есть шаблон — заполняйте его, не изобретайте свой. Пустые секции «Checklist: [ ] tests» с галочками наугад хуже честной строки «тестов на этот слой в проекте нет, проверил вручную так-то».

Пример 1. Фикс бага в API

Задача: при пустом списке заказов ручка отдаёт 500 вместо пустого массива. Junior backend, первая неделя.

Fix empty orders list returning 500.

Что: в GET /orders при отсутствии записей сервис бросал исключение на разборе None. Теперь возвращаем пустой список и 200.

Зачем: тикет JS-1842, воспроизводится на пустой базе после онбординга. Ломает кабинет менеджера.

Как проверить: поднять API по README, очистить таблицу orders или зайти под новым пользователем, вызвать GET /orders. Ожидание: 200 и []. Добавил тест test_list_orders_empty.

Риски: поведение для «пользователь не найден» не менял — там по-прежнему 404. Миграций нет.

Почему это проходит: ревьюер за пять секунд понимает вход, выход и как не сломать руками. Diff маленький, тест есть, граница изменения названа.

Пример 2. Правка документации как первый вклад

Вы полдня поднимали проект, потому что в README была старая команда миграций. Это нормальный первый PR, если правка точная.

Update local migrate command in README.

Что: в разделе «Local setup» команда миграций заменена на ту, что реально использует CI и Makefile. Добавил примечание про переменную DATABASE_URL для пустой локальной базы.

Зачем: по текущей инструкции сервис не поднимается на чистой машине. Сам упёрся в это в день 1.

Как проверить: пройти шаги README с нуля до make test на новой ветке. Главное: миграции применяются без ручного psql.

Риски: прод-документацию и runbook дежурства не трогал. Только local setup.

Такой PR не «мелкий». Он экономит следующий онбординг и показывает, что вы фиксируете трение, а не копите его в личных заметках.

Что проверять в diff до отправки

Откройте файлы изменений и пробегитесь по списку. Это быстрее, чем цикл «ревьюер нашёл мусор — вы извиняетесь».

  • Нет файлов, которые вы не собирались менять. Если форматтер переписал чужой модуль — откатите и ограничьте форматтер своим куском, как принято в репо.
  • Нет секретов, дампов, .env, персональных данных из локальной базы.
  • Имена тестов и фикстур понятны без открытия файла.
  • Комментарии в коде объясняют неочевидное «почему», а не пересказывают строку.
  • Если меняли контракт API — обновили клиента, схему, пример в доке. Иначе это уже второй сюрприз для соседней команды.

Большой diff с пометкой «это в основном пробелы» всё равно большой. Ревьюер читает его как большой. Дробите или уберите шум.

Как проходить ревью

Комментарий «здесь лучше так» — не оценка личности. Отвечайте по существу, коротко, в том же треде.

  • Согласны — чините и пишите «поправил в следующем коммите» или «force-push после squash, как принято». Не молчите: иначе ревьюер не знает, можно ли смотреть снова.
  • Не поняли — спросите: «хотите вынести в отдельную функцию или достаточно переименовать?» Два варианта лучше, чем «не понял, объясните культуру команды».
  • Не согласны — один аргумент и риск. «Если вынести сейчас, придётся трогать ещё три вызова, предлагаю тикет на follow-up». Не «в прошлой компании мы так не делали».
  • Никогда не принимайте «исправлю потом» на блокере: падающий тест, секреты, ломающий контракт. Потом не случится.

Если ревьюер пропал на день — один пинг в тикете или в треде PR с ссылкой и фразой «готов ко второму проходу». Второй пинг через день. Третий уже эскалация менеджеру на 1:1, не в общий чат.

После мёржа напишите в командный канал одну строку, если так принято: что влилось и зачем. На удалёнке это часть видимости, не хвастовство. Как держать эту видимость дальше — в плане первых 30/60/90 дней и в материале про испытательный срок.

Частые ошибки новичка

  • PR «заодно». Фикс бага плюс переименование плюс линтер на полмодуля. Ревьюер не знает, что оценивать. Разнесите.
  • Пустое описание при идеальном коде. Код без контекста всё равно тормозит. Тикет и шаги проверки обязательны.
  • «WIP, но уже смотрите». Если не готово — черновик или не открывайте. Открытый PR, который красный и без описания, занимает очередь.
  • Обида на стиль. Нейминг и порядок импортов в чужом репо — не место защищать вкус. Сначала конвенции репо, потом ваш вкус в новом коде, если команда не против.
  • Тишина после правок. Поправили и ждете телепатии. Напишите, что можно смотреть снова.
  • Гигантский первый коммит «весь модуль». Даже если фича одна, историю и ревью проще есть кусками, если так принято. Спросите ментора до того, как набрать 40 файлов.

Чек-лист перед Create pull request

  • Задача умещается в одно предложение.
  • Ветка от актуального main / master / develop — как в репо.
  • Линтер и тесты локально зелёные на вашем срезе.
  • Diff без отладки, без чужого переформатирования, без секретов.
  • Заголовок понятен без открытия.
  • В описании есть что / зачем / как проверить / риски.
  • Есть ссылка на тикет или явное «тикета нет, баг из онбординга».
  • Вы сами прошли шаги проверки ещё раз после последнего коммита.
  • Ревьюеры проставлены по правилу команды, не «все подряд».

Частые вопросы

Можно ли первый PR делать в документацию, или это «не настоящая работа»?

Можно, если правка снимает реальное трение. Документация, которая врёт, ломает следующих людей. Не делайте косметику ради галочки: перестановка заголовков без факта не считается вкладом.

Сколько файлов нормально для первого PR?

Столько, сколько нужно для одного изменения. Часто это 1–5 файлов. Если уже 15 — скорее всего, смешали рефакторинг. Спросите ментора, дробить ли, до того как открывать.

Нужно ли писать тесты, если в модуле их почти нет?

Если команда пишет тесты на новый код — напишите. Если слой исторически без тестов, не устраивайте крестовый поход в первом PR. Один тест на ваше поведение — хороший минимум. Полное покрытие модуля — отдельный разговор.

Что делать, если CI красный из-за флака, не из-за меня?

Перезапуск по правилам команды, ссылка на известный флак, короткий комментарий. Не маскируйте падение «у меня локально зелёное» без доказательства, что падает та же джоба на main.

Можно ли форс-пушить в ветку с открытым PR?

Только если так принято и ветка ваша. Если ревьюер уже комментировал строки, форс-пуш без предупреждения сбивает контекст. Напишите, что переписываете историю, или добавьте коммиты — как в соседних PR.

Как быть, если задачу оценили на день, а я копаюсь третий?

Не молчите до пятницы. Напишите, где застряли, что уже проверили, какой следующий вопрос. Первый PR имеет право занять дольше: вы ещё строите карту репозитория. Скрывать задержку хуже, чем быть медленнее ожидаемого.

Что сделать сейчас

Найдите один незакрытый кусок трения: баг из онбординга, врёт README, нет теста на очевидный случай. Соберите diff, заполните шаблон описания выше, прогоните чек-лист и откройте PR до конца этой недели — не «когда разберусь во всём проекте».

Если задачи ещё нет, попросите ментора или менеджера выдать именно маленький первый вклад. Параллельно держите открытым план 30/60/90: первый мёрж — это точка 30 дней, а не финал испытательного срока. Искать следующую работу этим текстом не надо. Если вы ещё на поиске и только готовитесь к выходу, сначала закройте оффер через каталог вакансий и систему из материала как найти работу — а PR начнёте уже в новом репозитории.